Investigate frontend WarBow "flag planted" showing for many consecutive accounts on localnet #51

Closed
opened 2026-04-23 05:41:05 +00:00 by PlasticDigits · 9 comments
PlasticDigits commented 2026-04-23 05:41:05 +00:00 (Migrated from gitlab.com)

Summary

Observed on localnet: multiple accounts in a row appear to show flags planted in the frontend (buy feed / buy highlights / rivalry narrative). This issue tracks whether that is a real bug (wrong wallet perspective, stale reads, indexer drift) or expected given how the Buy event encodes flagPlanted and how the UI interprets it.


How WarBow flags work (authoritative — onchain)

There is a single global pending-flag slot on TimeCurve:

  • warbowPendingFlagOwner — who may eventually claimWarBowFlag
  • warbowPendingFlagPlantAt — when their qualifying buy last (re)planted the flag

Flow

  1. Every successful _buy sets warbowPendingFlagOwner = msg.sender and warbowPendingFlagPlantAt = block.timestamp (the previous holder is cleared or penalized first if another buyer interrupts — see contract).
  2. claimWarBowFlag (while sale active): requires msg.sender == warbowPendingFlagOwner, now >= plantAt + WARBOW_FLAG_SILENCE_SEC (300s), then awards WARBOW_FLAG_CLAIM_BP (1000) BP and clears the slot.
  3. Interrupt before claim: If another address buys while a flag is pending, the pending slot is cleared. If that interrupt happens at or after plantAt + 300s, the former holder may take a 2 × WARBOW_FLAG_CLAIM_BP BP penalty (WarBowFlagPenalized); if before silence ends, no 2× penalty (they simply lose the claim window).

Game theory (why this exists)

  • Silence / coordination tension: After you buy, you want ~5 minutes with no other buyer so you can bank +1000 BP for free (beyond normal buy BP). That rewards “clearing the room” and patience.
  • Sniping / denial: Any other buyer resets who holds the pending flag to themselves and clears your exclusive claim. If they wait until after silence, they also punish slow claimers with the 2× BP hit — creating a race between claiming quickly after silence vs being sniped.
  • Net: It is a positional mini-game layered on the timer war — orthogonal to steals/guard/revenge but aligned with “momentum” narratives in the feed.

How it is coded today

Contract (contracts/src/TimeCurve.sol)

  • Pending state: warbowPendingFlagOwner, warbowPendingFlagPlantAt, constants WARBOW_FLAG_SILENCE_SEC, WARBOW_FLAG_CLAIM_BP.
  • _buy: Clears prior pending (with optional 2× penalty branch), then always assigns pending to msg.sender and updates plantAt.
  • Buy event: The Solidity emit passes flagPlanted as the literal true on every successful buy (not conditional on “new plant after clear” in the payload). See emit Buy(..., flagPenalty, true, ...).

Indexer (indexer/src/decoder.rs)

  • Decodes Buy.flagPlanted from logs into flag_planted on indexed buy rows — faithful to the event, so every modern Buy row carries flag_planted: true when the contract always emits true.

Frontend

Chain truth for “do I hold the pending flag?” (frontend/src/pages/TimeCurvePage.tsx)

  • Reads warbowPendingFlagOwner / warbowPendingFlagPlantAt via wagmi.
  • iHoldPlantFlag = connected wallet matches warbowPendingFlagOwner (case-insensitive).
  • canClaimWarBowFlag additionally requires sale phase active and ledger time past silence end.

Indexer-driven copy (per buy row) (frontend/src/lib/timeCurveUx.ts)

  • pickBuyHighlightStat, listBuyImpactTicks, buildBuyFeedNarrative treat buy.flag_planted as a signal and surface “Flag planted” / “flag planted” tags when no higher-priority WarBow/timer signals dominate.
  • Because the contract always emits true, many consecutive buyers will each have rows that can show flag-related highlights — even though only one address is the current warbowPendingFlagOwner.

Arena panel (frontend/src/pages/timecurve/TimeCurveSections.tsx)

  • “Flag planted. Silence ends at …” is gated by iHoldPlantFlag (not by indexer flag_planted), which is the correct wallet-specific behavior.

Tests / fixtures

  • frontend/src/lib/timeCurveUx.test.ts — expectations around flag_planted in UX helpers.
  • frontend/e2e/timecurve-live-buys-modals.spec.ts — mock buy uses flag_planted: false (may not reflect live contract encoding).

How it is documented

Location What it says (flag-related)
docs/product/primitives.md — Plant flag / claim flag Describes pending owner, silence, claim BP, interrupt + conditional 2× penalty. Also states Buy includes flagPlanted when a new plant occurs after clears — this does not match the current TimeCurve.sol emit, which is true on every buy.
skills/play-timecurve-warbow/SKILL.md Participant-facing flag rules; points to primitives.
docs/frontend/design.md UX framing: flag silence and when 2× penalty applies.
docs/frontend/timecurve-views.md Routes / Arena capabilities (buy, WarBow steal/guard/revenge/flag).
docs/qa/YO-TimeCurve-QA-Checklist.md B5 WarBow manual checks.
contracts/PARAMETERS.md WARBOW_FLAG_CLAIM_BP / silence 300s.
bots/timecurve/README.md Local swarm notes (parallel slots vs deterministic WarBow flag).

Cross-reference index (repo paths)

  • Onchain: contracts/src/TimeCurve.sol (_buy, claimWarBowFlag, WarBowFlagPenalized, WarBowFlagClaimed)
  • ABI / event string: frontend/src/lib/abis.ts (Buy event includes flagPlanted)
  • Indexer decode: indexer/src/decoder.rs (TimeCurveEvents::Buy → flag_planted)
  • API type: frontend/src/lib/indexerApi.ts (flag_planted?: boolean)
  • UX: frontend/src/lib/timeCurveUx.ts, frontend/src/pages/TimeCurvePage.tsx, frontend/src/pages/timecurve/TimeCurveSections.tsx
  • Protocol page (read-only reference): frontend/src/pages/TimeCurveProtocolPage.tsx (exposes warbowPendingFlag* views)
  • Docs: docs/product/primitives.md, docs/frontend/design.md, skills/play-timecurve-warbow/SKILL.md

Is the reported behavior expected?

Likely yes for indexer-driven buy rows, if “flag planted” is driven from Buy.flagPlanted: the field is always true in current bytecode, so rotating localnet accounts that each buy will each get rows that advertise flag planting — that is semantically “every buy replants the global pending flag to this buyer”, not “every buyer simultaneously holds a flag.”

Still worth validating in this issue

  1. Wallet switching: Confirm iHoldPlantFlag / canClaimWarBowFlag always track useAccount() and do not cache the wrong address on localnet.
  2. Copy / product: Decide whether UI should reword highlights (e.g. “Pending flag holder updated” vs “Flag planted”) or derive highlights from chain pending fields for clarity.
  3. Spec alignment: Either update docs/product/primitives.md to match the always-true event encoding, or change the contract (future) to emit a meaningful boolean and reindex — only if product wants flagPlanted to mean something narrower.

Suggested acceptance criteria

  • Reproduce on local stack; capture whether confusion is Arena panel vs buy feed / modals only.
  • Document conclusion: bug vs ABI/UI semantics vs docs drift.
  • If UX-only: adjust timeCurveUx messaging or priority so “flag planted” is not repeated for every ordinary buy unless intended.
  • If docs-only: fix primitives.md vs TimeCurve.sol mismatch on flagPlanted meaning.
## Summary Observed on **localnet**: **multiple accounts in a row** appear to show **flags planted** in the frontend (buy feed / buy highlights / rivalry narrative). This issue tracks whether that is a **real bug** (wrong wallet perspective, stale reads, indexer drift) or **expected** given how the **`Buy`** event encodes `flagPlanted` and how the UI interprets it. --- ## How WarBow flags work (authoritative — onchain) There is a **single global** pending-flag slot on `TimeCurve`: - **`warbowPendingFlagOwner`** — who may eventually **`claimWarBowFlag`** - **`warbowPendingFlagPlantAt`** — when their qualifying **buy** last (re)planted the flag **Flow** 1. Every successful **`_buy`** sets `warbowPendingFlagOwner = msg.sender` and `warbowPendingFlagPlantAt = block.timestamp` (the previous holder is cleared or penalized first if another buyer interrupts — see contract). 2. **`claimWarBowFlag`** (while sale active): requires `msg.sender == warbowPendingFlagOwner`, `now >= plantAt + WARBOW_FLAG_SILENCE_SEC` (**300s**), then awards **`WARBOW_FLAG_CLAIM_BP` (1000)** BP and clears the slot. 3. **Interrupt before claim:** If **another address** buys while a flag is pending, the pending slot is cleared. If that interrupt happens **at or after** `plantAt + 300s`, the former holder may take a **`2 × WARBOW_FLAG_CLAIM_BP`** BP penalty (`WarBowFlagPenalized`); if **before** silence ends, **no** 2× penalty (they simply lose the claim window). **Game theory (why this exists)** - **Silence / coordination tension:** After you buy, you want **~5 minutes with no other buyer** so you can bank **+1000 BP** for free (beyond normal buy BP). That rewards “clearing the room” and patience. - **Sniping / denial:** Any other buyer **resets** who holds the pending flag to themselves and clears your exclusive claim. If they wait until **after** silence, they also **punish** slow claimers with the **2× BP** hit — creating a race between **claiming quickly** after silence vs **being sniped**. - **Net:** It is a **positional mini-game** layered on the timer war — orthogonal to steals/guard/revenge but aligned with “momentum” narratives in the feed. --- ## How it is coded today ### Contract (`contracts/src/TimeCurve.sol`) - Pending state: `warbowPendingFlagOwner`, `warbowPendingFlagPlantAt`, constants `WARBOW_FLAG_SILENCE_SEC`, `WARBOW_FLAG_CLAIM_BP`. - **`_buy`:** Clears prior pending (with optional 2× penalty branch), then **always** assigns pending to `msg.sender` and updates `plantAt`. - **`Buy` event:** The Solidity emit passes **`flagPlanted` as the literal `true`** on every successful buy (not conditional on “new plant after clear” in the payload). See `emit Buy(..., flagPenalty, true, ...)`. ### Indexer (`indexer/src/decoder.rs`) - Decodes `Buy.flagPlanted` from logs into **`flag_planted`** on indexed buy rows — **faithful to the event**, so **every** modern `Buy` row carries `flag_planted: true` when the contract always emits `true`. ### Frontend **Chain truth for “do I hold the pending flag?”** (`frontend/src/pages/TimeCurvePage.tsx`) - Reads `warbowPendingFlagOwner` / `warbowPendingFlagPlantAt` via wagmi. - **`iHoldPlantFlag`** = connected wallet matches `warbowPendingFlagOwner` (case-insensitive). - **`canClaimWarBowFlag`** additionally requires sale phase active and ledger time past silence end. **Indexer-driven copy (per buy row)** (`frontend/src/lib/timeCurveUx.ts`) - **`pickBuyHighlightStat`**, **`listBuyImpactTicks`**, **`buildBuyFeedNarrative`** treat **`buy.flag_planted`** as a signal and surface **“Flag planted”** / **“flag planted”** tags when no higher-priority WarBow/timer signals dominate. - Because the contract always emits `true`, **many consecutive buyers** will each have rows that **can** show flag-related highlights — **even though** only **one** address is the current `warbowPendingFlagOwner`. **Arena panel** (`frontend/src/pages/timecurve/TimeCurveSections.tsx`) - “Flag planted. Silence ends at …” is gated by **`iHoldPlantFlag`** (not by indexer `flag_planted`), which is the **correct** wallet-specific behavior. ### Tests / fixtures - `frontend/src/lib/timeCurveUx.test.ts` — expectations around `flag_planted` in UX helpers. - `frontend/e2e/timecurve-live-buys-modals.spec.ts` — mock buy uses `flag_planted: false` (may not reflect live contract encoding). --- ## How it is documented | Location | What it says (flag-related) | |----------|----------------------------| | `docs/product/primitives.md` — *Plant flag / claim flag* | Describes pending owner, silence, claim BP, interrupt + conditional **2×** penalty. Also states **`Buy` includes `flagPlanted` when a new plant occurs after clears** — **this does not match** the current `TimeCurve.sol` emit, which is **`true` on every buy**. | | `skills/play-timecurve-warbow/SKILL.md` | Participant-facing flag rules; points to primitives. | | `docs/frontend/design.md` | UX framing: flag silence and when 2× penalty applies. | | `docs/frontend/timecurve-views.md` | Routes / Arena capabilities (buy, WarBow steal/guard/revenge/flag). | | `docs/qa/YO-TimeCurve-QA-Checklist.md` | B5 WarBow manual checks. | | `contracts/PARAMETERS.md` | `WARBOW_FLAG_CLAIM_BP` / silence **300s**. | | `bots/timecurve/README.md` | Local swarm notes (parallel slots vs deterministic WarBow flag). | --- ## Cross-reference index (repo paths) - **Onchain:** `contracts/src/TimeCurve.sol` (`_buy`, `claimWarBowFlag`, `WarBowFlagPenalized`, `WarBowFlagClaimed`) - **ABI / event string:** `frontend/src/lib/abis.ts` (`Buy` event includes `flagPlanted`) - **Indexer decode:** `indexer/src/decoder.rs` (`TimeCurveEvents::Buy` → `flag_planted`) - **API type:** `frontend/src/lib/indexerApi.ts` (`flag_planted?: boolean`) - **UX:** `frontend/src/lib/timeCurveUx.ts`, `frontend/src/pages/TimeCurvePage.tsx`, `frontend/src/pages/timecurve/TimeCurveSections.tsx` - **Protocol page (read-only reference):** `frontend/src/pages/TimeCurveProtocolPage.tsx` (exposes `warbowPendingFlag*` views) - **Docs:** `docs/product/primitives.md`, `docs/frontend/design.md`, `skills/play-timecurve-warbow/SKILL.md` --- ## Is the reported behavior expected? **Likely yes for indexer-driven buy rows**, if “flag planted” is driven from **`Buy.flagPlanted`**: the field is **always `true`** in current bytecode, so **rotating localnet accounts** that each buy will **each** get rows that advertise flag planting — that is **semantically “every buy replants the global pending flag to this buyer”**, not “every buyer simultaneously holds a flag.” **Still worth validating in this issue** 1. **Wallet switching:** Confirm `iHoldPlantFlag` / `canClaimWarBowFlag` always track **`useAccount()`** and do not cache the wrong address on localnet. 2. **Copy / product:** Decide whether UI should reword highlights (e.g. “Pending flag holder updated” vs “Flag planted”) or derive highlights from **chain** pending fields for clarity. 3. **Spec alignment:** Either **update `docs/product/primitives.md`** to match the always-`true` event encoding, or **change the contract** (future) to emit a meaningful boolean and reindex — only if product wants `flagPlanted` to mean something narrower. --- ## Suggested acceptance criteria - [ ] Reproduce on local stack; capture whether confusion is **Arena panel** vs **buy feed / modals** only. - [ ] Document conclusion: bug vs **ABI/UI semantics** vs **docs drift**. - [ ] If UX-only: adjust `timeCurveUx` messaging or priority so “flag planted” is not repeated for every ordinary buy unless intended. - [ ] If docs-only: fix `primitives.md` vs `TimeCurve.sol` mismatch on `flagPlanted` meaning.
PlasticDigits commented 2026-04-23 05:41:05 +00:00 (Migrated from gitlab.com)

assigned to @PlasticDigits

assigned to @PlasticDigits
PlasticDigits commented 2026-04-23 05:41:17 +00:00 (Migrated from gitlab.com)

changed the description

changed the description
PlasticDigits commented 2026-04-23 11:56:11 +00:00 (Migrated from gitlab.com)

Frontend also needs to display when flags are won or destroyed, and indicate if a flag is currently active and if so who is the placer and how many seconds left on it

Frontend also needs to display when flags are won or destroyed, and indicate if a flag is currently active and if so who is the placer and how many seconds left on it
PlasticDigits commented 2026-04-24 04:48:30 +00:00 (Migrated from gitlab.com)

mentioned in commit 8f303ef56a

mentioned in commit 8f303ef56ada1b358229fd124c6df6d9e9a1edae
PlasticDigits commented 2026-04-24 04:48:49 +00:00 (Migrated from gitlab.com)

Implemented on main (commit `8f303ef`).

Summary

  • Buy feed / highlights: Stopped treating indexer `flag_planted` as a meaningful WarBow signal — current `TimeCurve` emits `Buy.flagPlanted = true` on every successful buy, so that field does not identify “who holds the pending flag.”
  • Arena — pending flag (chain): New “Pending WarBow flag (chain)” panel: global holder (`warbowPendingFlagOwner`), seconds until silence ends (same ledger clock as the rest of the Arena), and claim-window copy. WarBow policy reads refetch every 1s and on new heads.
  • Rivalry feed: `flag_claimed` / `flag_penalized` narratives use Flag won / Flag destroyed (+ pending cleared tag on penalize).
  • Docs: `docs/product/primitives.md`, `docs/frontend/timecurve-views.md` (new section), `docs/testing/invariants-and-business-logic.md`; cross-links from `skills/play-timecurve-warbow/SKILL.md` and contributor `.cursor/skills/yieldomega-guardrails/SKILL.md`.

Verification checklist for @brouie

  • On localnet, open Arena → WarBow: with no pending slot, panel shows No pending flag; after a buy, holder matches the last buyer and countdown counts down toward silence end.
  • Buy feed / buy tiles: consecutive buys from different wallets no longer each show “Flag planted” / flag chip purely from indexer rows (penalty / hard reset / BP lines unchanged).
  • After silence + claim, rivalry feed shows Flag won; after late interrupt with penalty, feed shows Flag destroyed / pending cleared as appropriate.
  • Buy detail panel still lists the raw log field with label noting always true in current bytecode.
  • `frontend`: `npm run typecheck`, `npm run lint`, `npm test -- --run src/lib/timeCurveUx.test.ts` pass.

Issue left open for your sign-off.

Implemented on **main** (commit \`8f303ef\`). ### Summary - **Buy feed / highlights:** Stopped treating indexer \`flag_planted\` as a meaningful WarBow signal — current \`TimeCurve\` emits \`Buy.flagPlanted = true\` on every successful buy, so that field does not identify “who holds the pending flag.” - **Arena — pending flag (chain):** New **“Pending WarBow flag (chain)”** panel: global holder (\`warbowPendingFlagOwner\`), **seconds until silence ends** (same ledger clock as the rest of the Arena), and **claim-window** copy. WarBow policy reads refetch every **1s** and on new heads. - **Rivalry feed:** \`flag_claimed\` / \`flag_penalized\` narratives use **Flag won** / **Flag destroyed** (+ **pending cleared** tag on penalize). - **Docs:** \`docs/product/primitives.md\`, \`docs/frontend/timecurve-views.md\` (new section), \`docs/testing/invariants-and-business-logic.md\`; cross-links from \`skills/play-timecurve-warbow/SKILL.md\` and contributor \`.cursor/skills/yieldomega-guardrails/SKILL.md\`. ### Verification checklist for @brouie - [ ] On **localnet**, open **Arena** → WarBow: with **no** pending slot, panel shows **No pending flag**; after a buy, **holder** matches the last buyer and **countdown** counts down toward silence end. - [ ] **Buy feed / buy tiles:** consecutive buys from **different** wallets **no longer** each show **“Flag planted”** / flag chip purely from indexer rows (penalty / hard reset / BP lines unchanged). - [ ] After silence + **claim**, rivalry feed shows **Flag won**; after **late interrupt** with penalty, feed shows **Flag destroyed** / **pending cleared** as appropriate. - [ ] **Buy detail** panel still lists the raw log field with label noting **always true in current bytecode**. - [ ] \`frontend\`: \`npm run typecheck\`, \`npm run lint\`, \`npm test -- --run src/lib/timeCurveUx.test.ts\` pass. Issue left **open** for your sign-off.
PlasticDigits commented 2026-04-24 05:06:14 +00:00 (Migrated from gitlab.com)

mentioned in issue #55

mentioned in issue #55
PlasticDigits commented 2026-04-24 05:13:28 +00:00 (Migrated from gitlab.com)

mentioned in issue #44

mentioned in issue #44
Brouie commented 2026-04-27 05:46:29 +00:00 (Migrated from gitlab.com)

@PlasticDigits verified on 8f303ef during browser walkthrough on live local-anvil stack (chain 31337, frontend at http://127.0.0.1:5173).

Visual verification — Arena page (/timecurve/arena)

PENDING WARBOW FLAG (CHAIN) panel:

  • Renders correctly with 'No pending flag' copy when warbowPendingFlagOwner is zero
  • Shows 'One global slot: warbowPendingFlagOwner / warbowPendingFlagPlantAt' rule explainer
  • Shows 'Sale is not live - flag claims are closed even if a slot still reads non-zero' (correct end-sale framing per cf6fe19)

Buy feed / Live Buys sidebar (4 historical buys from rich-state Part1):

  • Each buy tile shows WARBOW 250 BP + CLOCK +120s chips
  • No 'Flag planted' chip per buy — pre-#51 anti-pattern is gone, fix landed correctly
  • Buyer addresses, timestamps, charm amounts all render

Top Rivals + Chasing Pack:

  • Top Rivals shows top 3 BP holders (contract snapshot tag)
  • Chasing Pack shows next 4 BP holders, with 'Connected wallet' highlight on row 1 for 0xf3...2266 (the active session wallet) — correct identity tracking

Rivalry feed:

  • Shows 'No WarBow feed rows yet' — correct empty state since no claim/penalize events have fired in this rich-state setup

Frontend tests

cd frontend && npx vitest run:

  • 28/28 test files passing
  • 188/188 tests total

Spec items confirmed

  • iHoldPlantFlag / canClaimWarBowFlag track useAccount() correctly (Connected wallet highlight is dynamic, not cached)
  • Buy feed / buy tiles no longer show flag chip from raw indexer flag_planted (consistent with the 'Buy.flagPlanted = true on every buy in current bytecode' invariant, indexer field still surfaced raw at the buy detail level per spec)
  • Rivalry feed reserves Flag won / Flag destroyed narratives for actual flag_claimed / flag_penalized events, which are absent here as expected

Screenshot evidence captured

10 screenshots taken across Simple, Arena, Protocol views during this walkthrough. Closing #51 with a follow-up filed at #81 for an unrelated finding (frontend leaks mainnet RPC fetches to eth.merkle.io even when connected to local Anvil chain 31337 — CORS-blocked, hygiene issue, not blocking).

Closing #51.

@PlasticDigits verified on 8f303ef during browser walkthrough on live local-anvil stack (chain 31337, frontend at http://127.0.0.1:5173). ## Visual verification — Arena page (/timecurve/arena) PENDING WARBOW FLAG (CHAIN) panel: - Renders correctly with 'No pending flag' copy when warbowPendingFlagOwner is zero - Shows 'One global slot: warbowPendingFlagOwner / warbowPendingFlagPlantAt' rule explainer - Shows 'Sale is not live - flag claims are closed even if a slot still reads non-zero' (correct end-sale framing per cf6fe19) Buy feed / Live Buys sidebar (4 historical buys from rich-state Part1): - Each buy tile shows WARBOW 250 BP + CLOCK +120s chips - **No 'Flag planted' chip per buy** — pre-#51 anti-pattern is gone, fix landed correctly - Buyer addresses, timestamps, charm amounts all render Top Rivals + Chasing Pack: - Top Rivals shows top 3 BP holders (contract snapshot tag) - Chasing Pack shows next 4 BP holders, with 'Connected wallet' highlight on row 1 for 0xf3...2266 (the active session wallet) — correct identity tracking Rivalry feed: - Shows 'No WarBow feed rows yet' — correct empty state since no claim/penalize events have fired in this rich-state setup ## Frontend tests cd frontend && npx vitest run: - 28/28 test files passing - 188/188 tests total ## Spec items confirmed - iHoldPlantFlag / canClaimWarBowFlag track useAccount() correctly (Connected wallet highlight is dynamic, not cached) - Buy feed / buy tiles no longer show flag chip from raw indexer flag_planted (consistent with the 'Buy.flagPlanted = true on every buy in current bytecode' invariant, indexer field still surfaced raw at the buy detail level per spec) - Rivalry feed reserves Flag won / Flag destroyed narratives for actual flag_claimed / flag_penalized events, which are absent here as expected ## Screenshot evidence captured 10 screenshots taken across Simple, Arena, Protocol views during this walkthrough. Closing #51 with a follow-up filed at #81 for an unrelated finding (frontend leaks mainnet RPC fetches to eth.merkle.io even when connected to local Anvil chain 31337 — CORS-blocked, hygiene issue, not blocking). Closing #51.
Brouie (Migrated from gitlab.com) closed this issue 2026-04-27 05:46:30 +00:00
PlasticDigits commented 2026-05-19 08:06:28 +00:00 (Migrated from gitlab.com)

mentioned in issue #218

mentioned in issue #218
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
code/yieldomega#51
No description provided.