Overview
This issue documents the execution plan for completing IISA v1 and related improvements. The remaining work is organized into 5 sequential waves, with each wave building on the previous.
Wave Structure
Wave 1: IISA HTTP Hardening (7 issues)
Establish production-ready HTTP communication before deployment.
| Issue |
Title |
Priority |
| #507 |
Add timeout and retry logic to HTTP client |
high |
| #514 |
Define error handling and resilience policy |
medium |
| #519 |
Expand IISA configuration options |
medium |
| #509 |
Add comprehensive HTTP client tests |
medium |
| #517 |
Security review and harden IISA HTTP |
feature |
| #518 |
Add logging, metrics, and tracing |
feature |
| #508 |
Update documentation |
polish |
Rationale: The HTTP client is the critical integration point. Timeout/retry (#507) and error handling (#514) are foundational. Security (#517) and observability (#518) follow. Configuration (#519) exposes these settings. Tests (#509) validate the implementation. Documentation (#508) captures the final state.
Wave 2: Deployment & Release (2 issues)
Ship the hardened IISA to production.
| Issue |
Title |
Priority |
| #516 |
Plan and execute containerization release |
high |
| #515 |
Add Kubernetes deployment configuration |
feature |
Note: These issues are tracked here for coordination, but the implementation work happens in edgeandnode/subgraph-dips-indexer-selection. See also subgraph-dips-indexer-selection#1 for related production hardening tasks in that repo.
Rationale: With the HTTP client hardened and tested, the system is ready for deployment. K8s config (#515) enables deployment, and the release (#516) coordinates the rollout.
Wave 3: Agreement Lifecycle (2 issues)
Improve reliability and performance of agreement management.
| Issue |
Title |
Priority |
| #526 |
Database-side aggregation optimization |
medium |
| #524 |
Add periodic reassignment loop |
v1 |
Rationale: Post-deployment improvements. The reassignment loop (#524) handles indexer failures gracefully. DB aggregation (#526) optimizes the batch query introduced in PR #522.
#524 replaced with #550
Wave 4: Scalability Validation (1 issue)
Validate the system under production-like load.
| Issue |
Title |
Priority |
| #520 |
Validate HTTP payload at 25K subgraphs / 100 indexers |
investigate |
Rationale: With the system deployed and stable, validate that it handles the expected scale. This informs any further optimization needs.
Wave 5: Future Work (1 issue)
Deferred improvements for v2.
| Issue |
Title |
Priority |
| #525 |
Stale Created agreements timeout |
v2 |
Rationale: This is a v2 feature that addresses edge cases in agreement lifecycle. Lower priority than core v1 functionality.
Completed
Dependencies
Wave 1 ──► Wave 2 ──► Wave 3 ──► Wave 4 ──► Wave 5
│
└── Work in subgraph-dips-indexer-selection repo
Overview
This issue documents the execution plan for completing IISA v1 and related improvements. The remaining work is organized into 5 sequential waves, with each wave building on the previous.
Wave Structure
Wave 1: IISA HTTP Hardening (7 issues)
Establish production-ready HTTP communication before deployment.
Rationale: The HTTP client is the critical integration point. Timeout/retry (#507) and error handling (#514) are foundational. Security (#517) and observability (#518) follow. Configuration (#519) exposes these settings. Tests (#509) validate the implementation. Documentation (#508) captures the final state.
Wave 2: Deployment & Release (2 issues)
Ship the hardened IISA to production.
Rationale: With the HTTP client hardened and tested, the system is ready for deployment. K8s config (#515) enables deployment, and the release (#516) coordinates the rollout.
Wave 3: Agreement Lifecycle (2 issues)
Improve reliability and performance of agreement management.
Rationale: Post-deployment improvements. The reassignment loop (#524) handles indexer failures gracefully. DB aggregation (#526) optimizes the batch query introduced in PR #522.
#524 replaced with #550
Wave 4: Scalability Validation (1 issue)
Validate the system under production-like load.
Rationale: With the system deployed and stable, validate that it handles the expected scale. This informs any further optimization needs.
Wave 5: Future Work (1 issue)
Deferred improvements for v2.
Createdagreements lack timeout mechanism #525Rationale: This is a v2 feature that addresses edge cases in agreement lifecycle. Lower priority than core v1 functionality.
Completed
Dependencies