Replies: 7 comments 1 reply
Are #20, #21, #24 done? — deep status, checked against current
|
|
@abrahamnash — question on sequencing for the upcoming devnet release. P3 is essentially ready (see the progress readout on #145): all 8 core PRs merged, and what's left is P3-6.2 stress testing plus a couple of real remaining gaps (BL-11, the partial-slash penalty fraction). P4 (indexer/SDK/daemon), per the analysis above, is substantially coded but nothing has merged to Should we start merging P4 into @robertocarlous — you own @Santiagocetran — same for Trying to get a real picture of how close both integration branches actually are to mergeable before Abraham's call on sequencing above. |
|
Hi @umermjd11 I am checking the current status and i will report back on this |
|
Thanks for pulling this together @umermjd11 — really useful to see all four PRs in one picture. Here's where Short answer: no P3-side blocker. This is paced entirely by task_110926_14 and task_110926_15. Nothing in P3 touches the SDK/daemon surface and I'm not waiting on anyone else's PR. ProgressBoth tasks are planned and starting now. I'm going branch-ordered rather than task-ordered, so there's one forward-merge instead of two:
For BL-9 Part 1 I'm doing both candidates, Two things to correct, my fault for not flagging them soonerThe "frozen at
#31 also came out of draft on 2026-08-27, so the table's draft label is stale. #32 is correctly still draft. Good news for step 5: One merge hazard worth splitting out
While checking that I think I spotted a small live bug on Latent for now — nothing passes that state to |
|
@robertocarlous — separate question on
The alternative is running it platform-level — one (or a few, for redundancy) always-on indexer instance(s) everyone queries — but that's a real infrastructure commitment we don't have anywhere else in the stack: a server, uptime/monitoring, and eventually load-balancing/HA if query volume grows. That's a meaningfully different operational posture than "ship a CLI/daemon binary," and it has real cost and ops-ownership implications (who's on call for it). What's your take, given you designed the indexer — per-user local instance, platform-hosted, or something in between (e.g. platform-hosted by us for now with the schema/mappings open so anyone can self-host later)? Would help pin this down before @abrahamnash — looping you in on the cost side of this specifically. If Robbert's answer above points toward platform-hosted (or the hybrid option), that's an ongoing infra line item — server(s), monitoring, and eventual load-balancing/HA — that doesn't exist anywhere else in the stack today (everything else is self-hosted by each participant). Worth having your read on whether that's a cost we want to carry starting at DevNet 2.0/3.0, or only once testnet's real infrastructure spend is happening anyway. |
|
Hi @umermjd11 Both fixes are small and I can push them quickly: schema.graphql:412 — the multi-line field description uses single "..." instead of triple """...""" quotes, which breaks graph codegen. One-line fix. test_list_pending_requests.py — the 6 tests call list_pending_requests.callback(ctx, ...) directly instead of going through CliRunner.invoke(). Typer's .callback attribute is not reliably accessible that way across versions — that's the AttributeError: 'function' object has no attribute 'callback'. Fix is to rewrite them using CliRunner like every other test file in the suite. Both are same-day fixes. Since #72 is stacked directly on #29's branch head, once #29's fixes are pushed, #72 automatically includes them — no separate rebase step needed unless the push creates a divergence, in which case I'll force-with-lease and update #72 accordingly. On conflict with task_100926_12/task_100926_13 No conflict these are fully independent. task_100926_12/13 are pure Solidity work touching DINTaskCoordinator, DINTaskAuditor, DinValidatorStake, DinTreasury. The indexer branch touches subgraph/, the GraphQL layer in dincli/cli/dindao.py, and tests/ — zero file-level overlap, no sequencing dependency in either direction. I can push the indexer fixes in parallel; they don't need any P3 Solidity work to land first, and the P3 work doesn't need the indexer merged before it. One thing worth flagging as a follow-on (not a blocker): task_100926_13 §1(b/c) adds new registration-tracking events to DinValidatorStake. PR #72's subgraph handlers already wire the existing P3-staking events. When those new events land in Solidity, the subgraph will need corresponding handler additions — but that's a separate PR after the fact, same as the 5 currently-commented-out handlers waiting on GIStateChanged etc. On deployment modelMy recommendation: Subgraph Studio as the shared reference endpoint + docker-compose for local dev/self-hosting. Per-user local: The docker-compose in the branch already works for this. Graph node is block-cursor-based on clean or unclean shutdown, it resumes from its last committed block pointer, no gap risk (PostgreSQL WAL handles this). The "start from scratch" scenario only happens if you intentionally wipe the postgres volume. At Optimism Sepolia's chain density and DIN's current event volume, a full re-index from genesis probably takes minutes, not hours. So the resilience question is fine. The real problem with per-user-local as the primary model is UX: new users would have to spin up postgres + graph-node + IPFS locally just to query state — a real barrier for auditors and clients who only need list-pending-requests to work. Platform-hosted by DIN: Solves the UX problem but, as you noted, introduces an infra commitment that doesn't exist anywhere else in the stack. Server, monitoring, eventual HA — a different operational posture than "ship a binary." Subgraph Studio (The Graph's hosted service): Sidesteps the infra commitment entirely. You deploy the subgraph manifest to The Graph's hosted service, they run the indexer, and you get a stable query endpoint anyone can use. For a testnet subgraph at our query volume, cost is effectively zero — well within the free tier. The query API contract is identical whether someone hits the hosted endpoint or runs locally (same schema.graphql). For mainnet, this transitions naturally to The Graph's decentralized network (pay GRT signal rather than run servers). The only dependency is The Graph's hosted service uptime, which the local docker-compose fallback mitigates. My call:Subgraph Studio for the shared testnet endpoint, docker-compose local for dev and self-hosting. No infra line item for the team until mainnet, and the schema/API contract is unaffected by which backend is running it. I'll add a note to the PR description once the two blockers are fixed so the deployment model decision is documented there. |
|
On the indexer: why it's needed, how far we can go without one, and a phased path to DevNet 2.0/3.0 Stepping back from "who hosts it" — worth separating out why an indexer exists at all, how long we can defer it, and what "near-zero cost" actually looks like if we want a shared endpoint before testnet. Why an indexer is needed, and why it doesn't go away Some DIN queries are inherently list/filter/paginate/sort/historical-shaped: pending model requests, pending manifest requests, active/exiting/blacklisted validators, slash history, models by owner, governance dashboards. A contract can answer these two ways: maintain enumerable on-chain structures purely for read convenience (permanent gas cost on every write, growing storage, more surface to audit), or let the client reconstruct the answer by looping over RPC. That loop is O(total requests ever created), not O(pending requests). As long as "pending" stays a large fraction of "ever created," it's fine. The moment a network has real history — most requests already resolved, only a shrinking fraction still open — that ratio inverts, and the RPC-loop tax grows with total lifetime volume instead of with what the user actually asked for. That's not a hypothetical scaling concern, it's the specific shape of the data. So this isn't "avoid the indexer vs. build it" — it's "how long can we defer it," which is a real, answerable question. How far can DIN/dincli go without an indexer? Today, comfortably — Keeping it user-side (the DevNet 2.0/3.0 default) The existing design already supports this cleanly: ship the subgraph manifest/mappings/schema (PR #29/#72 — 34 entities, 4 data sources, 31 handlers) plus the docker-compose (Postgres + graph-node + IPFS) as the default local path, with A near-zero-cost shared endpoint, if we want one before testnet Worth being precise here since "free" undersells it: The Graph's old free Hosted Service is deprecated. Subgraph Studio's dev endpoint is free but capped at 3,000 queries/day and explicitly not meant for public production traffic. An actual publicly-queryable shared endpoint means publishing to The Graph Network, which needs a small GRT curation signal before indexers pick it up — a real but likely trivial cost at our volume — after which query consumers get a Free Plan (100k queries/month). Either way, The Graph's own infrastructure does the running; there's no DIN server, uptime, or on-call commitment either option. If we want a shared reference endpoint for DevNet 2.0/3.0, that's the near-zero-cost way to do it, distinct from standing up our own hosted indexer. When a fully-infrastructured indexer actually becomes necessary At testnet launch. Testnet is already the point where DIN takes on real infra (RPC/IPFS capacity, monitoring/alerting, on-call) for external, non-technical users — a self-run, monitored indexer (or a paid managed arrangement) is naturally one more line item in that buildout, not a new category of cost introduced early. Concrete triggers: query volume/reliability needs exceed what Studio's cap or the Network's free tier can serve to a broad external audience, or query shapes grow (governance dashboards, cross-contract analytics) beyond what a shared best-effort endpoint comfortably handles. Indexer roadmap
|
|
Thanks for the full breakdown On deployment model:Understood on the Subgraph Studio correction — I understated it as "near-zero cost for low volume," but 3k/day isn't viable even for a dev-scale shared endpoint. The Graph Network path (small GRT curation signal → free consumer tier at 100k/month) is the right shared-endpoint option, and keeps the DIN team out of the infra business until testnet. The local docker-compose default for DevNet 2.0/3.0 makes sense — the GraphQL-first / RPC-fallback already in the branch means nothing breaks for anyone not running it. On #29 fixes:Pushing these today — schema.graphql triple-quote fix and test_list_pending_requests.py rewrite to CliRunner. #72 inherits them automatically since it's stacked on #29's branch. On roadmap step 2 (task-level + platform-level event additions): The 5 commented-out handlers in #72's subgraph.yaml are blocked on: LocalModelSubmitted, T1AggregationSubmitted, T2AggregationSubmitted, GIStateChanged on DINTaskCoordinator.sol/DINTaskAuditor.sol isOpenSource/fee on ModelRegistrationRequested and requester on ManifestUpdateRequested on DinModelRegistry.sol On the SQLite embedded cache: Agreed it's the right long-term answer for lighter roles who don't want the full docker stack. I'll leave it out of the current PR scope and note it as a follow-up item. |
Uh oh!
There was an error while loading. Please reload this page.
Scope
Merge-order analysis and recommendation for the four open P4 PRs — #29, #72 (indexer track) and #31, #32 (SDK/daemon track). This is a recommendation only; nothing has been merged. Full per-PR deep-verification and merge-proposal-table comments are already posted on each PR (linked below) — this discussion is the cross-PR picture that ties them together.
Structure
Both integration branches are currently frozen at the same commit and have not picked up any
develophistory since being cut:feat/din-indexer— at805ce9d, 187 commits behinddevelopfeat/din-sdk— at805ce9d, 187 commits behinddevelopWithin each track, the second PR is stacked directly on the first — its head branch already contains the first PR's commits in full:
This is why GitHub's raw diff stats for #72 (185 files) and #32 (257 files) are misleading — most of that is the earlier PR's own unmerged content riding along, not net-new work. The actual incremental diffs are much smaller (#72: 6 files / +962-380; #32: 27 files / +2185-9), confirmed independently in each PR's deep-verification comment.
PR #72 also folds in PR #65 (
feat/p3-staking) locally — that dependency is already satisfied, #65 merged todevelopon 2026-08-10.Per-PR findings
feat/din-indexerfeat/din-indexerfeat/din-sdkfeat/din-sdkPR #29 — GitHub shows
mergeable: CLEAN, but that's git-level only; two functional blockers surfaced under actual execution:subgraph/schema.graphql:412— invalid GraphQL syntax (a description spanning 3 lines with"..."instead of"""...""") breaksgraph codegenoutright.tests/test_list_pending_requests.py— all 6 tests fail (AttributeError: 'function' object has no attribute 'callback') because it's the only test file in the suite that doesn't go throughCliRunner. Thedindao.pyGraphQL→RPC fallback logic it's testing is itself correct — only the test invocation is broken.Full detail: deep verification · merge-proposal table
PR #72 — six new P3-staking event handlers verified byte-for-byte against the live
DinValidatorStake.solsource;Jailed-status semantics confirmed to mirror the contract's own guard exactly.graph buildfails, but only on #29'sregistry.tsissue above (out of scope for #72, already flagged on #29).Full detail: deep verification · merge-proposal table
PR #31 — 406 passed, 1 real (non-flaky) failure:
tests/test_connect_wallet.py::test_load_account_no_red_xmonkeypatches the now-vestigialdincli.cli.utils.CONFIG_DIR/WALLETS_DIR, but real path resolution has moved todincli.sdk.wallet.resolve_wallet_path(), which the test never patches — it fell through to a real local wallet file and hit a MAC mismatch decrypting it with the test's dummy password. Root-caused via tracing. Everything else (import-boundary purity,state.py/serialize.pyverbatim-move + encoder correctness, shim-module integrity) held up.Full detail: deep verification · merge-proposal table
PR #32 — real incremental scope is 13 commits / 27 files (not GitHub's inflated 257-file stat). 248 passed, 0 failures, including a genuine regression-guard test for
/health-endpoint hermeticity (no socket/GPU probes on the polled path).Full detail: deep verification · merge-proposal table
Recommended merge order
Nothing below has been executed — recommendation only.
feat/din-indexer— fix the schema.graphql syntax error and the broken test harness first; both are small, real fixes, not design issues.feat/din-indexer, after feat(indexer): implement DIN Protocol subgraph — platform + task-level contracts #29 — it's stacked on feat(indexer): implement DIN Protocol subgraph — platform + task-level contracts #29's commits, so it can't land first without pulling feat(indexer): implement DIN Protocol subgraph — platform + task-level contracts #29's unreviewed content in as a side effect.feat/din-sdk— fix the wallet-test isolation gap; still draft, needs the author to confirm merge-readiness.feat/din-sdk, after SDK #20: dincli/sdk foundation — loaders, manifest/runtime, state/serialize, wallet/session/tx, operations #31 — stacked the same way as feat(indexer): wire P3-staking events — ValidatorJailed/Reactivated, governable MIN_STAKE, JailEvent entity #72/feat(indexer): implement DIN Protocol subgraph — platform + task-level contracts #29.feat/din-indexer→developandfeat/din-sdk→develop, each as its own merge. Both branches are 187 commits stale againstdevelop, so expect real conflict resolution rather than a fast-forward — this is worth budgeting time for separately from the PR-level fixes above.All reactions