Skip to content

PR_READY.md

Latest commit

 

History

History
146 lines (113 loc) · 4.56 KB

PR_READY.md

File metadata and controls

146 lines (113 loc) · 4.56 KB
Raw

✅ Pull Request Ready - Issue #275

Status

The graceful degradation state fix is complete and ready for PR creation.

All code is committed, tested, and pushed to the remote branch.

Quick Links

What's Included

Code Changes (4 files modified)

  • ✅ backend/src/degradation.rs - Refactored to use database
  • ✅ backend/src/db.rs - Added migration #12 and 3 database methods
  • ✅ backend/src/main.rs - Initialize degradation state and register routes
  • ✅ docs/graceful-degradation.md - Updated documentation

Supporting Documentation (5 files created)

  • ✅ DEGRADATION_FIX_SUMMARY.md - Technical overview
  • ✅ CODE_CHANGES_SUMMARY.md - Detailed code diffs
  • ✅ TESTING_DEGRADATION_FIX.md - Testing guide
  • ✅ IMPLEMENTATION_CHECKLIST.md - Verification checklist
  • ✅ DEPLOY_README.md - Deployment guide

Test Coverage

  • ✅ 8 comprehensive unit tests
    • 6 regression tests (backward compatibility)
    • 1 shared store test (multi-instance)
    • 1 persistence test (restart safety)

Commit Message

fix: move degradation state to shared SQL-backed registry

Move capability status registry from process-local in-memory storage to a
shared SQL database, ensuring all instances in a load-balanced deployment
see consistent degradation state.

Previously, marking a capability degraded on instance A did not affect
instance B's behavior. Each instance maintained its own HashMap, leading
to contradictory guidance to clients during outages. This fix ensures:

- All instances read from and write to the same capability_statuses table
- Changes are immediately visible across the fleet
- Status persists across process restarts
- Single-instance behavior remains unchanged

Changes:
- Add capability_statuses table (migration #12) with indexed lookups
- Refactor DegradationState to use Arc<Db> instead of Mutex<HashMap>
- Implement set_capability_status(), get_capability_status(), list_capability_statuses()
- Update HTTP handlers to return Result types with proper error handling
- Register /admin/capabilities, /capabilities/negotiate endpoints
- Add comprehensive tests proving shared store and persistence
- Update graceful-degradation.md documentation

Closes #275

Statistics

Metric Value
Files Changed 4
Files Created 5
Lines Added 2,351
Lines Removed 79
Commits 1
Tests 8
Documentation Pages 5

To Create the PR

Option 1: GitHub Web UI (Recommended)

  1. Visit: https://github.com/deborahamoni0-prog/ethos-contracts-backend/pull/new/fix/shared-degradation-state
  2. Use the description from PR_CREATION_INSTRUCTIONS.md
  3. Click "Create pull request"

Option 2: GitHub CLI (if authentication is set up)

gh pr create \
  --title "fix: move degradation state to shared SQL-backed registry" \
  -F PR_CREATION_INSTRUCTIONS.md \
  -B main \
  -H fix/shared-degradation-state

PR Description Template

See PR_CREATION_INSTRUCTIONS.md for the complete PR description with:

  • Problem statement
  • Solution approach
  • Key benefits
  • Testing details
  • Documentation updates
  • Related issue reference (#275)

What This Fixes

Before (Broken)

  • Instance A: marks "payments" degraded → database updated
  • Instance B: doesn't see change → reports "payments" as full
  • Client on instance A: told to use fallback ✓
  • Client on instance B: told service is fully available ✗
  • Result: Contradictory guidance during outage

After (Fixed)

  • Instance A: marks "payments" degraded → database updated
  • Instance B: reads same database → reports "payments" as degraded
  • Client on instance A: told to use fallback ✓
  • Client on instance B: told to use fallback ✓
  • Result: Consistent guidance across all instances

Verification Checklist

  • Code changes complete
  • All tests written and passing
  • Documentation updated
  • Supporting docs created
  • Branch created and pushed
  • Commit message clear and descriptive
  • Closes issue #275
  • No breaking changes
  • Ready for code review

Next Steps

  1. Create the PR using one of the methods above
  2. PR will trigger CI checks (lint, format, tests)
  3. Code review team reviews changes
  4. Address any review feedback
  5. Merge to main when approved
  6. Deploy to production

Status: ✅ READY FOR PR CREATION

The implementation is complete, tested, documented, and ready for merge.