Skip to content

Improve failure handling, identity validation, notification storage, and database configuration. - #2081

Merged
david-rocca merged 5 commits into
devfrom
dr_11022026_fixes
Nov 3, 2026
Merged

david-rocca merged 5 commits into
devfrom
dr_11022026_fixes

Conversation

@david-rocca

@david-rocca david-rocca commented Nov 3, 2026 •

Copy link
Copy Markdown
Collaborator

Summary

The changes prevent asynchronous failures from leaving requests unresolved, validate the final state of user and organization updates, remove the notification inbox document-size bottleneck, and align runtime and migration database targets.

Notification endpoints retain complete-inbox responses and require no UI changes.

Important Changes

  • Async error handling: Add local catches around affected asynchronous operations. Cleanup failures preserve the original operation error, and session teardown cannot replace an already-committed success. Unexpected failures return controlled responses.
  • Username validation: Check the final destination organization and username within existing transactions. Reject destination duplicates and allow move-plus-rename requests when the conflicting username exists only in the source organization.
  • Organization validation: Check final organization names and aliases during creation, updates, and review approval. Reject stale approvals that introduce collisions and roll back associated changes.
  • Notification storage: Store notifications individually instead of accumulating one inbox document. Preserve existing notification UUIDs during migration, independent recipient IDs, complete inbox retrieval, and POST/DELETE behavior. Conversation updates and notification delivery remain transactional.
  • Database configuration: Share connection resolution through the existing database helper. Add npm run db:preflight to inspect the resolved target without connecting or exposing credentials. Reject conflicting database settings.
  • Test coverage: Consolidate duplicate tests and cover controlled failures, destination collisions, rollback, notification capacity/contracts, migration recovery, and database configuration.

Testing

  • 1,078 integration tests passed: bash -i -c "MONGO_DB_NAME=cve_test npm run test:integration:replicas"
  • 426 unit tests passed: bash -i -c "npm run test:unit-tests"
  • Source/test lint: zero errors, four existing warnings.
  • Notification migration lint and generated OpenAPI checks passed.

Deployment smoke checks:

  • Verify valid user creation/moves and rejection of destination duplicates.
  • Verify stale organization approvals fail without changing organization, review, or audit state.
  • Verify notification delivery, complete inbox retrieval, and recipient-specific dismissal.
  • Verify registry hierarchy/creation failures return descriptive 400 responses with request UUIDs matching server logs.
  • Run database preflight in the application and migration launch environments.

Notes

Observable API changes:

Area Result
Registry hierarchy failures Retain HTTP 400; return ORG_HIERARCHY_FAILED with a request reference.
Registry organization creation failures Change HTTP 450 to 400 ORG_CREATE_FAILED, with a request reference.
Organization-list and review failures Retain HTTP 500 with a fixed public error body.
Secret-reset failures Retain HTTP 450 and the nested error envelope; replace serialized exceptions with a controlled error.
Unexpected dependency errors Stop treating arbitrary dependency status/message fields as request-parsing errors; use controlled server-error handling.
Identity validation Newly detected conflicts use existing 400 USER_EXISTS, 403 DUPLICATE_USERNAME, or 400 ALIAS_COLLISION responses.
  • Migration dependency: Requires migrations submodule commit e453293f, containing notification migration 20261102-02. Stop notification reads and writes during conversion and avoid mixing old and new storage writers. Rollback can be refused if an inbox exceeds the old document-size limit.
  • Configuration: Production MONGO_CONN_STRING overrides and conflicting MONGO_DB_NAME settings now fail validation.
  • Concurrency: Username and organization-name availability checks run within existing transactions. Simultaneous claims can still race.
  • Notification ordering: Retrieval remains newest-first and unbounded. Records with identical timestamps can have a different relative order.

Address tickets A08, A09, A10, A21, and A28 using the existing
controller, repository, and configuration patterns.

- Handle async and cleanup failures locally with controlled public errors.
  Registry hierarchy and creation failures return descriptive 400 responses
  with request references for server-side diagnostics.
- Validate destination usernames within existing transactions and check final
  organization identity changes, without additional identity write guards.
- Store notifications individually while retaining complete inbox responses
  and independent recipient identifiers; include the migration gitlink.
- Share database configuration through the existing db helper.
- Consolidate obsolete and duplicate tests while retaining regression coverage.

Validation: 1,078 integration tests and 426 unit tests passed. Source/test
lint reported no errors and four existing warnings; migration lint and
generated OpenAPI checks passed.

@jdalphond-mitre jdalphond-mitre left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is a lot going on here. I did a bunch of manual testing which all returned expected results.

@david-rocca
david-rocca merged commit db96d5b into dev Nov 3, 2026
9 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants