Stabilizing MyZubster: Runtime Hardening, Test Architecture, Payments, Auth and Security
Over the latest development cycle, we have been working on a broad stabilization pass across MyZubster.
The goal has not been to add another layer of features.
The goal has been to make sure the architecture we already have behaves consistently across runtime, authentication, payments, social identity, treasury data, security boundaries, and automated testing.
A major part of this work has been distinguishing between two very different classes of failures:
- real production defects, which require changes to application logic;
- outdated or brittle tests, where production behavior is correct but the test still reflects an older implementation.
That distinction has been important throughout the process.
Our rule has been:
Never change production behavior, real data, or security controls simply to make a test green.
If production is wrong, we fix production.
If production is correct, we update the test contract.
1. Runtime stabilization
One of the first areas we stabilized was the backend runtime itself.
The gateway now starts through the canonical repository runtime and explicitly initializes the backend database connection before accepting traffic.
This avoids a class of problems where the HTTP server becomes available before MongoDB-backed services are actually ready.
The production startup sequence now follows the expected lifecycle:
text
load application
↓
initialize backend
↓
connect database
↓
start gateway
↓
accept traffic
Graceful shutdown handling is also part of the runtime flow so the process can terminate cleanly on system signals.
The active gateway runtime has been consolidated under systemd, removing the duplicate process-management path that previously existed through PM2.
This significantly reduces ambiguity around which process owns the production port and which codebase is actually running.
2. Social identity persistence across Mongoose versions
A particularly interesting issue appeared in the social identity layer.
The project currently has two parts of the codebase using different Mongoose versions.
One side was producing a MongoDB ObjectId from one BSON implementation, while another Mongoose instance expected an ObjectId backed by a different BSON version.
That resulted in errors such as:
BSONVersionError:
Unsupported BSON version
The safest boundary between the two Mongoose environments is now a primitive value rather than an ObjectId instance.
For example:
MetaverseCharacter.findOne({
accountUserId: String(user._id)
});
and when creating the related entity:
accountUserId: String(user._id)
This avoids leaking BSON-specific objects across independent Mongoose runtimes.
We also hardened GitHub identity persistence.
Instead of replacing the entire nested GitHub object, fields are now updated independently:
user.set('github.id', String(profile.id));
user.set('github.verifiedAt', new Date());
if (profile.login !== undefined) {
user.set('github.login', profile.login);
}
if (profile.avatarUrl !== undefined) {
user.set('github.avatarUrl', profile.avatarUrl);
}
if (profile.profileUrl !== undefined) {
user.set('github.profileUrl', profile.profileUrl);
}
if (publicSnapshot) {
user.set('github.publicSnapshot', publicSnapshot);
}
This prevents Mongoose from accidentally casting optional nested properties to unintended values.
The social identity suite is now green.
This work was pushed in:
2056e542
fix(auth): stabilize social identity persistence across mongoose versions
3. PartyContext security hardening
Another important fix involved real-time session context.
Previously, under degraded database conditions, a session identifier supplied by the client could be reflected back as if it represented a verified server-side session.
That is not a safe trust boundary.
The system now fails closed.
If the database cannot verify the supplied session identifier, the degraded context reports the session state as unknown rather than trusting the client-provided value.
Conceptually:
client sessionId
↓
database verification
↓
verified? ── yes ──> trusted session
│
no
↓
unknown / unavailable
We also tightened validation so session-related identifiers cannot silently bypass the intended validation path.
The PartyContext test suites now pass completely.
The security fix was pushed in:
db6f3532
fix(party): fail closed on unverified session identifiers
4. Unified payment architecture
The payment layer has also been undergoing consolidation.
Older tests and parts of the application still referenced legacy Zorgax-specific payment structures.
The newer architecture uses a shared payment model and unified checkout flow.
The current model is based around:
PaymentIntent
ZorgaxPurchase
Entitlement
Quote
Verifier
Catalog
instead of maintaining a separate payment implementation for each product.
The legacy Zorgax payment intent model is now effectively an alias around the shared payment intent architecture.
Tests have been migrated accordingly.
Relevant stabilization commits include:
3eae8b9e
test(zorgax): migrate payment tests to unified checkout
and:
7d1f08a2
test(zorgax): align payment intent tests with unified model
This reduces duplicate payment logic and makes verification rules reusable across the product.
5. Fail-closed payment verification
Payment verification continues to follow a server-owned contract.
Expected recipient and amount values come from the server-side order, never from arbitrary client input.
Conceptually:
{
asset,
network,
expectedRecipient,
expectedAtomicAmount,
txId
}
Only the transaction identifier comes from the verification request.
The expected recipient and amount remain controlled by the backend.
Unsupported assets are rejected before verifier execution, and incomplete payment intents cannot reach the verification layer.
This behavior is now covered by native Node tests.
6. Separating Jest tests from native node:test
During the full test-suite review we found an architectural problem in the test runner itself.
Some test files were written using Node's native testing API:
const test = require('node:test');
const assert = require('node:assert/strict');
but their filenames caused Jest to discover them.
The result was misleading:
Your test suite must contain at least one test
The tests themselves were valid.
They simply belonged to a different runner.
We now explicitly separate the two systems.
Jest ignores native Node tests:
testPathIgnorePatterns: [
'/node_modules/',
'/frontend/',
'/src/services/marketplaceOrderPaymentPolicy\\.test\\.js$',
'\\.node\\.test\\.js$'
]
while package.json defines a dedicated Node test runner:
{
"test": "jest",
"test:node": "node --test src/services/marketplaceOrderPaymentPolicy.test.js tests/kefirHandDelivery.node.test.js",
"posttest": "npm run test:node"
}
The native Node suite currently passes:
8 tests
8 passed
0 failed
This was pushed in:
860a8573
test: run native node tests outside jest
This is a better testing architecture than forcing every test into Jest simply because Jest is the main runner.
7. Making tests semantic instead of formatting-dependent
A recurring theme during stabilization has been brittle source-code assertions.
For example, some tests were checking exact formatting such as:
failure: 'storage_gate'
while the implementation contained:
failure:'storage_gate'
The behavior was identical.
The test was not testing behavior anymore.
It was testing whitespace.
We replaced those assertions with semantic regular expressions:
expect(serverSource)
.toMatch(/failure\s*:\s*['"]storage_gate['"]/);
The same strategy was applied to health-route wiring and several Zorgax runtime assertions.
The affected suites are now green.
This batch was pushed in:
a9f378fb
test: align zorgax contracts with current runtime
8. Payment Dashboard: removing environment-dependent assumptions
The Payment Dashboard exposed another class of test problem.
An older test assumed treasury funding inputs would always be empty:
expect(res.body.items).toEqual([]);
That assumption stopped being valid once a real canonical funding input existed in the repository.
Deleting the funding data just to satisfy the test would have been exactly the wrong solution.
Instead, the test now validates the actual contract.
It checks that the response contains a valid funding input collection and that every funding input remains non-authoritative for bounty approval:
expect(Array.isArray(res.body.items)).toBe(true);
res.body.items.forEach((item) => {
expect(item).toMatchObject({
kind: 'FUNDING_INPUT',
approvesBounty: false
});
});
This preserves an important treasury rule:
Incoming funds do not automatically approve bounty payments.
The Payment Dashboard suite now passes:
20 tests
20 passed
0 failed
This fix has been validated locally and is the next small change to commit and push.
9. MYZ accounting boundaries
The Payment Dashboard work also reinforced several accounting boundaries already present in the application.
The canonical MYZ balance is derived from recorded ledger entries.
Historical MongoDB credit records remain explicitly separated from the canonical spendable balance.
The backend does not silently convert legacy records into spendable MYZ.
The current contract makes that distinction visible:
canonical RECORDED ledger entries
≠
legacy MongoDB credit history
This is intentional.
Financial state should never be inferred from legacy storage without an explicit migration policy.
10. Zorgax assistant and live research
The Zorgax assistant suite is almost completely green.
Current result:
7 passed
1 failed
The remaining failure is not a failed external search.
Both research providers are being used.
The issue is only ordering:
expected first source: google_news
actual first source: wikipedia
The current result still reports both providers.
Before changing anything, we need to inspect whether:
Google News → Wikipedia
is still a required product rule,
or whether sources are intentionally being re-ranked after retrieval.
This is exactly the kind of situation where changing production just to satisfy an old test would be risky.
So this test is intentionally being left until the intended ranking contract is confirmed.
11. Kefir marketplace contract
The Kefir marketplace has another contract that still needs review.
One part of the current implementation allows a kefir culture exchange to operate as:
FREE
or:
BARTER
provided that the exchange remains non-commercial.
However, an older test describes kefir cultures as strictly:
free donations only
The implementation and test therefore encode two different product rules.
Before changing either side, we need to decide what the canonical policy actually is:
Option A
FREE only
Option B
FREE + non-commercial barter
This is a product-contract decision, not something the test runner should decide for us.
12. Cultural API privacy review
The next significant technical area is the Cultural API.
Several existing tests appear to reference older field names such as:
organizerId
claimedByUserId
publicMeetingPoint
approximateArea
while the current implementation uses concepts such as:
ownerId
location.publicText
location.restrictedText
The privacy behavior is particularly important here.
Public API responses must never expose restricted location information.
The current implementation explicitly excludes restricted location data from public reads.
Before updating any tests, we are reviewing:
ownership semantics
public location projection
private event behavior
authorized release rules
artist profile ownership
The goal is not merely to make the Cultural API tests green.
The goal is to make sure the tests reflect the current privacy model without weakening it.
13. Additional stabilization already completed
Several smaller but important fixes have also landed during this stabilization cycle.
These include:
Redis runtime support
Redis runtime dependencies were added where required without unnecessarily modifying package ownership.
BTC circular dependency cleanup
A circular dependency affecting Bitcoin-related runtime code was removed.
AI budget controls
Zorgax AI routing and monthly budget behavior now have dedicated test coverage.
Realtime membership
Realtime membership checks were changed to fail closed instead of assuming access during uncertain state.
Access-control hardening
Zorgax access and entitlement flows received additional coverage and contract alignment.
Current branch state
The stabilization work is being performed on:
feat/myz-188-university-developer-community-e2e
Important stabilization commits currently include:
2056e542
fix(auth): stabilize social identity persistence across mongoose versions
db6f3532
fix(party): fail closed on unverified session identifiers
860a8573
test: run native node tests outside jest
a9f378fb
test: align zorgax contracts with current runtime
Additional payment and runtime stabilization commits were completed earlier in the branch as well.
We are keeping unrelated verifier work outside these commits so the stabilization history remains reviewable and isolated.
What remains
The main remaining work is now much smaller and more focused.
Payment Dashboard
The deterministic funding-input test is green locally.
Next step:
commit
push
Cultural API
Review the current models, routes and privacy projections.
Determine which failing tests are legacy contracts and whether any expose real privacy regressions.
Zorgax research source ordering
Determine whether Google News must be first for time-sensitive queries or whether source ordering is intentionally relevance-based.
Then update either:
implementation
or:
test contract
based on the intended behavior.
Kefir marketplace contract
Confirm the canonical business rule:
FREE only
versus:
FREE + non-commercial BARTER
Remaining UI/source-inspection tests
Some UI tests still rely on exact source strings.
Those need to be converted to behavioral or semantic assertions where possible.
Full regression run
Once the remaining targeted failures are resolved, the final validation will include:
npm test
including the native Node test runner.
After that:
git diff --check
git status --short
followed by a final review of all remaining changes.
Final objective
The goal of this stabilization cycle is not simply:
make Jest green
The actual goal is:
production behavior is correct
+
security boundaries fail closed
+
financial state remains explicit
+
tests reflect current contracts
+
runtime startup is deterministic
+
legacy assumptions are removed
A green test suite is useful only when it represents the system we actually intend to run.
That is the standard we are applying across MyZubster before the final branch merge and deployment.
Next milestone
The next milestone is straightforward:
close remaining targeted failures
↓
run full regression suite
↓
review working tree
↓
merge
↓
deploy
↓
production smoke tests
At that point, the branch should represent a significantly cleaner and more trustworthy baseline for the next development phase of MyZubster.
Top comments (0)