feat(cybergym): say when the lane is IDLE rather than broken - #240
Merged
Merged
Conversation
An empty CyberGym vector had one name for two different events. A fresh, authenticated, complete report in which nobody scored above zero -- the lane worked, there was nothing to pay -- burned as `no_uid_mapping`, the same reason a registration problem produces, and a sibling of `no_report` / `stale` / `unauthenticated`. So nothing downstream could tell an idle lane from a broken one. That distinction is the prerequisite for any N=0 policy (wallscaler's review of #147 asked for exactly this): "pay compute when CyberGym is idle" implemented on today's reasons would also pay compute when the CyberGym feed is merely DOWN, which is the case that must keep burning. `idle_no_winners` is now returned when the tournament produced no winners at all; a winner that exists but maps to no UID stays `no_uid_mapping`, because that is a fault. The bridge records `lane_idle` alongside. No weights change: the share still forfeits to burn exactly as before.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Prerequisite for #147, and the part of it that is safe to land now. No weights change.
The problem
An empty CyberGym vector had one name for two different events:
no_uid_mappingno_uid_mappingno_report,stale,unauthenticatedThe first is not a fault — the lane worked and there was nothing to pay. The others are. Nothing downstream could tell them apart.
Why it matters
This is what wallscaler's review of #147 asked for. "Pay compute when CyberGym is idle", implemented on today's reasons, would also pay compute when the CyberGym feed is simply down — and a stale feed paying the compute lane is exactly the failure that must keep burning.
What changes
idle_no_winnerswhen the tournament produced no winners at all;no_uid_mappingstays for a winner that exists but cannot be paid. The bridge recordslane_idlebeside it.Weights are untouched — the share still forfeits to burn exactly as before. This only gives the event a name that a later policy can key off.
On #147 itself
I am leaving it open rather than merging it. wallscaler's F1 stands: the
no_contributionbranch it keys off cannot fire from the real bridge (an enabled positive-fraction spec always forfeits or contributes, so a zero-winner tick returnsokwith{burn_uid: 0.30}), so the redirect never happens and the validator would gain an accepted shape with no producer. Making it real also means moving a forfeited lane share to another lane, which contradicts the exportedunproven_lane_behaviorcontract andTHIN_SUBNET_DESIGN.md— a call for jared and wallscaler together, not something to slip in behind a merge. This PR is the piece that is needed either way.54 passedin the adapter suite (adds 2: the idle case and the mapping-failure case).