🚀 MyZubster Development Update — Sepolia E2E, Google OAuth & I-ECO-01 Infrastructure Stabilization
Today we completed a major infrastructure stabilization phase across the MyZubster Sepolia E2E environment and the connected I-ECO-01 / UrbanLab Escrow infrastructure.
The work focused on three critical areas: Google OAuth authentication, PM2 runtime configuration, and the stability of the I-ECO-01 Node.js service.
The result is a significantly cleaner and more stable development environment, with the main backend services running correctly and several previously hidden configuration issues identified and resolved.
🔐 Google OAuth — End-to-End Backend Flow Completed
A major part of today's work was dedicated to validating the Google authentication flow used by MyZubster.
The OAuth implementation was inspected from the initial authentication request all the way through the Google callback and backend processing.
We verified the public authentication endpoint and confirmed that MyZubster correctly generates the Google authorization request with the expected Client ID and callback URL.
The Sepolia callback is now correctly configured as:
https://sepolia.myzubster.com/api/auth/social/google/callback
During debugging, the backend was instrumented with additional OAuth tracing so that each important stage of the authentication flow could be observed directly from the PM2 logs.
The callback successfully reached the MyZubster backend with both the authorization code and signed state parameter.
An initial failure was then isolated during the token exchange stage.
Google returned:
401 invalid_client
with an indication that the configured client secret was invalid.
This allowed us to distinguish the problem from several other possible causes such as an incorrect callback URL, broken routing, invalid OAuth state, Cloudflare routing, frontend behavior, or an unavailable authentication provider.
After correcting the OAuth configuration, the backend successfully completed the Google authentication process.
The final trace reached:
OAUTH-CALLBACK-ENTER
followed by:
OAUTH-CALLBACK-SUCCESS
This confirms that the Google OAuth backend flow is operational.
🌐 Sepolia Runtime URL Configuration
Another issue was discovered after successful Google authentication.
Although the .env configuration correctly referenced:
https://sepolia.myzubster.com
the running PM2 process was still capable of using stale runtime environment values.
This caused successful authentication attempts to redirect users toward an older Vercel deployment instead of the intended Sepolia environment.
The runtime configuration was inspected at multiple levels:
• .env configuration
• Node.js + dotenv environment
• PM2 process environment
• OAuth callback generation
• frontend redirect generation
• running process configuration
The Sepolia runtime was then explicitly aligned so that the active backend process uses:
FRONTEND_URL=https://sepolia.myzubster.com
PUBLIC_APP_URL=https://sepolia.myzubster.com
GATEWAY_PUBLIC_URL=https://sepolia.myzubster.com
The active PM2 process was verified directly after the update.
This was important because having the correct value inside .env is not sufficient if a long-running process manager is still carrying older environment state.
🏭 I-ECO-01 / UrbanLab Investigation
During the infrastructure review we also discovered a serious stability problem affecting the I-ECO-01 / UrbanLab service.
The PM2 process had accumulated more than 6.5 million restarts.
Despite appearing as online in PM2, the process was continuously crashing and being restarted.
This is an important operational lesson: an online status alone does not necessarily mean that a service is healthy.
We inspected:
• PM2 process configuration
• executable path
• working directory
• restart counter
• process PID
• CPU usage
• Node.js error logs
• package dependencies
• server entrypoint
• health endpoint
The active process was confirmed to be executing:
/opt/I-ECO-01/server.js
🔎 Root Cause Identified
The crash loop was traced to missing Node.js dependencies.
The I-ECO-01 server.js required several modules that were not declared or installed in the project dependencies.
The missing packages were:
helmet
socket.io
winston
The server was failing immediately at:
require('helmet')
with:
MODULE_NOT_FOUND
Because PM2 was configured to automatically restart the process, every crash immediately triggered another launch attempt.
This created the extremely high restart count.
🔧 Dependency Repair
The complete set of external dependencies referenced by the server entrypoint was inspected before modifying the project.
The missing dependencies were then installed and added to package.json.
The resulting dependency set now includes the required server components:
• Express
• CORS
• dotenv
• Mongoose
• Helmet
• Socket.IO
• Winston
Each newly installed package was then independently loaded through Node.js to confirm that module resolution was working correctly.
All three previously missing modules passed the verification.
✅ UrbanLab Restart Loop Resolved
After repairing the dependencies, the UrbanLab service was restarted and monitored.
The server successfully initialized the Escrow controller and started listening on port 5002.
MongoDB also connected successfully.
Most importantly, we performed a timed stability test rather than relying only on PM2's reported status.
Before the test:
PID: 1026452
Restart count: 6548384
After waiting 15 seconds:
PID: 1026452
Restart count: 6548384
The PID remained unchanged and the restart counter did not increase.
This confirms that the restart loop was successfully stopped.
UrbanLab is now running as a stable process rather than continuously crashing and restarting.
❤️ I-ECO-01 Health Check
The service health endpoint was tested directly on the VPS:
http://127.0.0.1:5002/health
The service returned a healthy response reporting:
status: ok
service: I-ECO-01
mongodb: connected
This provides direct application-level confirmation that the service is alive and its database connection is operational.
🔐 Escrow Multisig Service
The I-ECO-01 Escrow controller is also initializing successfully.
The active configuration reports:
Multisig threshold: 2/3
Escrow timeout: 24 hours
Escrow fee: 0.5%
The service exposes its Escrow API and initializes WebSocket support alongside the HTTP server.
This gives the I-ECO-01 environment the foundation required for the next stages of escrow and transaction-flow testing.
📡 WebSocket Infrastructure
Socket.IO is now installed and successfully loaded by the server.
The service initializes WebSocket functionality together with the main HTTP server on port 5002.
This prepares the infrastructure for real-time communication between the backend and connected MyZubster / UrbanLab components.
🍃 MongoDB Connectivity
MongoDB connectivity was verified after the dependency repair.
The server reports:
MongoDB connected
and the health endpoint independently reports:
mongodb: connected
This is particularly important because application startup alone would not demonstrate that the persistence layer is actually available.
⚙️ PM2 & VPS Infrastructure
The broader VPS process environment was also inspected.
The system currently includes services for:
• MyZubster Sepolia backend
• MyZubster Sepolia frontend
• MyZubster Social
• MyZubster Web
• UrbanLab / I-ECO-01
• Cloudflared
PM2 itself is managed through systemd using the pm2-root service.
This means the process manager is integrated with the VPS boot environment rather than existing only inside an interactive shell session.
The corrected process state can therefore be persisted through PM2 after stability verification.
☁️ Cloudflare / Public Routing
The public Sepolia environment continues to operate through the existing Cloudflare infrastructure.
The public MyZubster Sepolia endpoint remains:
https://sepolia.myzubster.com
while the relevant backend services remain bound locally on the VPS.
This keeps internal services separated from the public entrypoint while allowing the Sepolia environment to expose the required application routes.
🧪 Why This Debugging Phase Was Important
Several of today's issues demonstrate why infrastructure validation must go beyond checking whether a process simply says online.
We encountered three very different classes of problems:
1. OAuth configuration mismatch
Google authentication reached the correct backend but failed during token exchange because of an invalid client credential.
2. Runtime environment mismatch
The .env file contained the correct Sepolia URLs, while the running application could still operate with stale process-level configuration.
3. Dependency-driven restart loop
PM2 displayed the UrbanLab service as online while it was actually crashing and restarting continuously because required Node.js packages were missing.
Each issue required validation at a different layer.
📊 Current Development Status
MyZubster Sepolia public environment: ✅ Operational
Google OAuth provider detection: ✅ Operational
Google OAuth callback: ✅ Operational
Google OAuth backend token flow: ✅ Completed successfully
OAuth callback state/code handling: ✅ Verified
Sepolia frontend redirect configuration: ✅ Corrected
PM2 runtime environment: ✅ Corrected
I-ECO-01 / UrbanLab startup: ✅ Operational
UrbanLab restart loop: ✅ Resolved
Node.js dependencies: ✅ Repaired
MongoDB connectivity: ✅ Verified
I-ECO-01 health endpoint: ✅ Healthy
Escrow controller initialization: ✅ Operational
2-of-3 Escrow configuration: ✅ Loaded
WebSocket infrastructure: ✅ Initialized
PM2/systemd infrastructure: ✅ Verified
🔒 Security
No API keys, OAuth secrets, database credentials, wallet private keys, JWT secrets, or other sensitive configuration values are included in this development update.
Infrastructure credentials remain environment-level configuration and must never be committed to public repositories or included in public debugging output.
Credential rotation is also part of the security process whenever secrets may have been exposed during development or debugging.
🛣️ Next Phase
With the core infrastructure stabilized, development can move away from basic process recovery and toward higher-level integration testing.
The next stages can focus on:
• complete browser-level Google authentication verification
• social-login ticket exchange and session persistence
• Sepolia frontend/backend integration
• authenticated user flows
• wallet integration testing
• Escrow API testing
• multisig workflow validation
• WebSocket event testing
• failure and recovery scenarios
• production-readiness checks
The important milestone is that we now have a much more predictable foundation.
Google OAuth can complete successfully on the backend, the Sepolia runtime configuration is aligned with the intended public environment, MongoDB is connected, and I-ECO-01 is no longer trapped in a restart loop.
Infrastructure debugging is not just about making a process start — it is about proving that every layer remains healthy after it starts.
Today, we moved MyZubster another significant step in that direction.
Top comments (0)