Retire stale tier claims, fabricated defaults, and dead config paths - #952
Merged
Conversation
…ig paths Sweep of the tier claims surface for numbers and names that stopped being true, plus config paths that fabricate values nothing should read: - /v1/graphs/tiers never advertised AI credits: the feature generator read a monthly_credits key that has never existed in graph.yml. Credits now come from BillingConfig, the same source the catalog uses. - get_lbug_tier_config no longer fabricates storage_limit_gb (500), monthly_credits (10000), or api_rate_multiplier (1.0) — keys that never existed in graph.yml and that no consumer reads. Their sources of truth are GraphTierConfig, BillingConfig, and RateLimitConfig. - DEFAULT_CHUNK_SIZE_ROWS drops 1M -> 250k. The fallback kept m7g.large's chunk after ladybug-standard moved to m7g.medium — the same class of OOM-guardrail drift the row-cap fallbacks fixed — and is now pinned by the same invariant test. - Dead code removed: CreditService.check_storage_limit and get_storage_limit_violations (no callers anywhere), and GraphTierConfig.get_storage_cap_gb (tests only). set_storage_override stays: it is the setter for the override admin storage reporting honors. - OpenAPI examples for the limits endpoint now show real post-resize values; the shared-repository example previously showed a measured 125.3 GB usage the endpoint can no longer return. - Stale prose: download-limits docstring (real values are 10/20/40 and SEC starter=1/advanced=4), "requires Large/XLarge tier" on a tier where Standard has had subgraphs since the resize, Enterprise/Premium and r7g-ladder comments, "professional workloads" in graph.yml, and the instance-storage docstring that still called the enforced cap "reporting, not enforcement". - The Dagster backup job's validation guard is now subgraph-aware, and an unused shared-repo check in MCP strategy selection is gone. Full suite: 11,422 passed with one test updated (it pinned the drifted 1M fallback and now derives from the constant); remaining failures are the two pre-existing test_incremental_materialize cases that reproduce on main.
…runs
Four claims the platform made and did not keep, each aligned to reality:
- Deprovisioning promised 90/180/365-day backup hosting by tier. The S3
lifecycle rule deletes backup objects at 90 days and the final backup
creates no GraphBackup row, so the tier-aware cleanup cannot extend it
either — Large and XLarge's extended hosting physically never happened.
All tiers now promise the 90 days the infrastructure delivers, pinned
by a test against the lifecycle ceiling.
- Backup retention accepted up to 2555 days (7 years) while the same
lifecycle rule destroyed the object at 90, leaving COMPLETED records
pointing at deleted objects. The request field now caps at 90, the
per-tier clamp applies even when the graph row or tier is missing
(it previously skipped entirely), and the clamp is visible: the
operation envelope reports the effective retention and says when it
was capped. The UI defaulted to 90 days and a Standard customer was
silently given 7 with no indication anywhere.
- Repository plans have always advertised agent_calls_per_* volume
limits; nothing ever passed operation="agent" to the volume limiter,
so the advertised numbers were unenforced. The operator surface (auto,
specific, batch) now applies shared-repository access + agent volume
limits through the same path query/mcp/search already use.
- /v1/offering described repository subscriptions as per-organization
("all organization members share access"). Access, credits, and volume
limits all key on the subscribing user; the copy now says per_user.
And the same tier claimed "4 GB RAM" in /offering but "3GB RAM" in
/v1/graphs/tiers features — the latter reported the LadybugDB budget,
not the machine. Both now advertise instance RAM; the memory_mb field
description no longer calls the instance budget "memory allocated to
your graph".
Full suite: 11,426 passed; only failures are the two pre-existing
test_incremental_materialize cases that reproduce on main.
Align backup, agent-limit, and offering claims with what runs
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.
Sweep of the tier claims surface for numbers and names that stopped being true, plus config paths that fabricate values nothing should read. Net −126 lines.
Claims that silently vanished or drifted
/v1/graphs/tiersnever advertised AI credits. The feature generator read amonthly_creditskey that has never existed in graph.yml, so the credits feature string was unreachable for every tier. It now derives fromBillingConfig— the same source the catalog uses, same pattern as the multiplier fix in Differentiate rate limits by tier and bucket per graph #948.DEFAULT_CHUNK_SIZE_ROWSdrops 1M → 250k. The chunked-materialization fallback kept m7g.large's chunk after ladybug-standard moved to m7g.medium — the same class of OOM-guardrail drift the row-cap fallbacks fixed in v1.6.14 — and is now pinned by the same invariant test so it cannot drift again./v1/graphs/{id}/limitsnow show real post-resize values. The shared-repository example previously showed a measured 125.3 GB usage the endpoint can no longer return, backup numbers from no config, and pre-resize row caps.Fabricated defaults removed
env.get_lbug_tier_config()no longer inventsstorage_limit_gb: 500,monthly_credits: 10000, orapi_rate_multiplier: 1.0— keys that never existed in graph.yml, so the dict only ever returned the fallback constants. No consumer reads them (verified across graph_api and the API); their sources of truth areGraphTierConfig,BillingConfig, andRateLimitConfig. The env tests that pinned the fabrication now pin the absence.Dead code removed
CreditService.check_storage_limitandget_storage_limit_violations— no callers anywhere (router, job, sensor, or CLI).set_storage_overridestays: it is the setter for the override that admin storage reporting honors.GraphTierConfig.get_storage_cap_gb— test-only.Stale prose corrected
Download-limits docstring (claimed 2/4/10; real values are 10/20/40, and SEC starter=1/advanced=4), the "requires Large/XLarge tier" OpenAPI description (Standard has had subgraphs since the resize), Enterprise/Premium and r7g-instance-ladder comments, "professional workloads" in graph.yml, and the instance-storage docstring that still called the enforced cap "soft — used for reporting, not enforcement." The Dagster backup job's graph-id validation guard is also now subgraph-aware.
Testing
Full suite: 11,422 passed. One existing test was updated rather than fixed — it pinned the drifted 1M fallback and now derives the expected batch count from the constant. Remaining failures are the two pre-existing
test_incremental_materializecases that reproduce onmain.