Skip to content

refactor: remove batch configuration mechanism#77

Merged
lwshang merged 2 commits into
mainfrom
refactor/remove-batch-configuration
Jun 5, 2026
Merged

refactor: remove batch configuration mechanism#77
lwshang merged 2 commits into
mainfrom
refactor/remove-batch-configuration

Conversation

@lwshang
Copy link
Copy Markdown
Collaborator

@lwshang lwshang commented Jun 5, 2026

Summary

The configure / get_configuration endpoints exposed three upload limits — max_batches, max_chunks, max_bytes — all defaulting to None (unlimited). Nothing ever set them: the sync-plugin, the only client and the only contract that matters, never calls configure. So the limits were always inactive and every limit check was dead code.

This removes the whole mechanism rather than keeping a config surface for a feature that did nothing in practice.

What changed

Commit 1 — remove the configuration mechanism (505 deletions)

  • assets.did: dropped ConfigurationResponse / ConfigureArguments types and the get_configuration / configure endpoints
  • types.rs: removed both IDL structs (including the Option<Option<u64>> tri-state)
  • state.rs: removed the Configuration struct, the configuration field, both methods, and the restore line
  • stable.rs: removed StableConfiguration, its two From impls, and the StableState field
  • batch.rs: removed the three limit checks plus the now-dead chunk_content_total_size field and compute_last_chunk_data helper
  • tests.rs: removed the configuration_methods and enforce_limits modules

Commit 2 — make create_batch infallible
With the limits gone, create_batch had no remaining error path. Dropped the Result<BatchId, String> wrapper: the State method returns BatchId directly, the wrapper builds the response without a match, and the test call sites lose their .unwrap().

Behavior

Uploads are now unbounded at the application layer — same as before in practice, since no client set these limits. Only authorized/controller principals can create batches at all, and the IC heap cap remains the backstop.

No backward-compatibility concern: pre-launch, no production instances, no persisted state to migrate.

Verification

  • cargo test -p canister-core — 87 passed
  • cargo test -p canister — candid-compatibility check passes (hand-edited assets.did matches generated interface)
  • cargo test -p e2e — 14 passed
  • cargo clippy -p canister-core -p canister --all-targets — clean

🤖 Generated with Claude Code

lwshang and others added 2 commits June 5, 2026 13:07
The configure/get_configuration endpoints exposed three upload limits
(max_batches, max_chunks, max_bytes), all defaulting to unlimited. Nothing
ever set them — the sync-plugin, the only client, never calls configure — so
the limits were always inactive and the limit-checking code was dead.

Remove the entire surface: the IDL types, the Configuration struct and its
stable-state persistence, the limit checks in batch.rs (plus the now-dead
chunk_content_total_size bookkeeping and compute_last_chunk_data helper), and
the configuration_methods/enforce_limits tests.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
With the batch limits gone, create_batch has no remaining error path — it
always returned Ok. Drop the Result<BatchId, String> wrapper: the State
method now returns BatchId directly, the canister-core wrapper builds the
response without a match, and the test call sites lose their .unwrap().

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@lwshang lwshang marked this pull request as ready for review June 5, 2026 17:19
@lwshang lwshang requested a review from a team as a code owner June 5, 2026 17:19
@lwshang lwshang merged commit c0a6527 into main Jun 5, 2026
6 checks passed
@lwshang lwshang deleted the refactor/remove-batch-configuration branch June 5, 2026 17:19
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant