113 lines
3.3 KiB
Markdown
113 lines
3.3 KiB
Markdown
---
|
|
phase: 03-gateway-config-broadcast
|
|
plan: 01
|
|
type: execute
|
|
wave: 1
|
|
depends_on: []
|
|
files_modified: []
|
|
autonomous: true
|
|
requirements: []
|
|
user_setup: []
|
|
|
|
must_haves:
|
|
truths:
|
|
- "Existing broadcast mechanism documented"
|
|
- "Route -> Service -> Downstream flow understood"
|
|
- "Config change events verified working"
|
|
artifacts:
|
|
- path: ".planning/phases/03-gateway-config-broadcast/03-SUMMARY.md"
|
|
provides: "Phase execution summary"
|
|
key_links: []
|
|
---
|
|
|
|
<objective>
|
|
Analyze and document the existing gateway configuration broadcast mechanism. Understand the complete chain from route configuration to downstream services, and verify the config change event broadcasting works correctly.
|
|
</objective>
|
|
|
|
<context>
|
|
@.planning/phases/01-gateway-config-management/01-SUMMARY.md
|
|
@.planning/phases/01-gateway-config-management/01-PLAN.md
|
|
|
|
## Existing Implementation (from Phase 1)
|
|
|
|
The broadcast mechanism uses PostgreSQL NOTIFY:
|
|
- **Channel:** `gateway_config_changed`
|
|
- **Event types:** service, route, instance, gateway
|
|
- **Actions:** create, update, delete, reload
|
|
- **Service:** ConfigNotificationService.cs
|
|
- **Integration:** GatewayService.cs triggers broadcast on all CRUD operations
|
|
</context>
|
|
|
|
<tasks>
|
|
|
|
<task type="auto">
|
|
<name>Task 1: Analyze existing broadcast implementation</name>
|
|
<files>src/Services/ConfigNotificationService.cs, src/Services/GatewayService.cs</files>
|
|
<action>
|
|
Analyze the existing implementation to understand:
|
|
1. How ConfigNotificationService works (PostgreSQL NOTIFY)
|
|
2. How GatewayService triggers broadcasts on CRUD operations
|
|
3. What event types and payloads are sent
|
|
|
|
Read the source files and document the findings.
|
|
</action>
|
|
<verify>
|
|
<automated>Files exist and contain notification logic</automated>
|
|
</verify>
|
|
<done>Implementation analysis complete, findings documented</done>
|
|
</task>
|
|
|
|
<task type="auto">
|
|
<name>Task 2: Map route -> service -> downstream flow</name>
|
|
<files></files>
|
|
<action>
|
|
Document the complete configuration chain:
|
|
1. How routes are defined in Console
|
|
2. How routes map to services
|
|
3. How services are discovered by downstream Gateway
|
|
4. When config changes, how the broadcast reaches downstream
|
|
|
|
Reference existing code in src/Models/, src/Services/, src/Controllers/
|
|
</action>
|
|
<verify>
|
|
<automated>Flow documentation created</automated>
|
|
</verify>
|
|
<done>Configuration chain documented</done>
|
|
</task>
|
|
|
|
<task type="auto">
|
|
<name>Task 3: Verify broadcast events work end-to-end</name>
|
|
<files></files>
|
|
<action>
|
|
Verify the broadcast mechanism:
|
|
1. Check if PostgreSQL LISTEN/NOTIFY is properly configured
|
|
2. Verify ReloadGatewayAsync sends the correct event
|
|
3. Confirm all CRUD operations (service/route/instance) trigger broadcasts
|
|
4. Test end-to-end flow if possible
|
|
</action>
|
|
<verify>
|
|
<automated>Build succeeds, API endpoints functional</automated>
|
|
</verify>
|
|
<done>Broadcast verification complete</done>
|
|
</task>
|
|
|
|
</tasks>
|
|
|
|
<verification>
|
|
1. Read and analyze ConfigNotificationService.cs
|
|
2. Read and analyze GatewayService.cs
|
|
3. Document route -> service -> downstream flow
|
|
4. Verify build passes
|
|
</verification>
|
|
|
|
<success_criteria>
|
|
- [x] Existing broadcast implementation analyzed
|
|
- [x] Configuration chain documented
|
|
- [x] Broadcast events verified
|
|
- [x] Summary created
|
|
</success_criteria>
|
|
|
|
<output>
|
|
After completion, create `.planning/phases/03-gateway-config-broadcast/03-SUMMARY.md`
|
|
</output>
|