Skip to content

chore(uploads): document 16 GiB upload size limit - #137

Open
hotdata-automation[bot] wants to merge 1 commit into
mainfrom
openapi-update-34435683593
Open

chore(uploads): document 16 GiB upload size limit#137
hotdata-automation[bot] wants to merge 1 commit into
mainfrom
openapi-update-34435683593

Conversation

@hotdata-automation

Copy link
Copy Markdown
Contributor

Auto-generated from the updated HotData OpenAPI spec.
Source: https://github.com/hotdata-dev/www/pull/425

@hotdata-automation
hotdata-automation Bot requested a review from a team as a code owner September 10, 2026 04:04
@hotdata-automation
hotdata-automation Bot requested review from zfarrell and removed request for a team September 10, 2026 04:04
@hotdata-automation
hotdata-automation Bot enabled auto-merge (squash) September 10, 2026 04:04
Comment thread CHANGELOG.md

### Changed

- chore(uploads): document 16 GiB upload size limit

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The Unreleased section omits every breaking change in this diff.

Failure scenario: a caller on 0.16.0 sets key_determines on AddManagedTableRequest. CHANGELOG.md:38 documents that field as a 0.15.0 addition. The caller upgrades and the build fails with no field named key_determines. The changelog names only an upload doc edit, so the rename is invisible.

Add entries for the following, using the **Breaking:** marker already used at CHANGELOG.md:50, :56, :59 and :63.

  • Breaking: key_determines is renamed to constant_per_key on AddManagedTableDecl, AddManagedTableRequest and DatabaseDefaultTableDecl.
  • Breaking: TableInfo gains a required constant_per_key field, so TableInfo::new takes one more argument.
  • Breaking: JobType gains the TableConstantsUpdate variant. JobType is not #[non_exhaustive], so a downstream exhaustive match stops compiling.
  • Added: set_managed_table_constant_per_key, set_database_table_constant_per_key, ManagedTableConstantPerKeyResponse and UpdateManagedTableRequest.

CI does not catch this. scripts/check-release.py:63 returns early while the Cargo.toml version is unchanged.

Comment thread src/apis/databases_api.rs
}

/// Replace the columns a table declares constant for a given key: for every row, any other row sharing its key holds the same value of these columns. Declaring this lets a keyed mutation (`delete`, `update`, `upsert`) narrow its search for prior versions to the values the upload carries. Unlike `partition_by` and `sorted_by`, this is NOT fixed when the table is created — it changes only which files a mutation opens, never how rows are written — so a populated table can adopt it with no rewrite, taking effect on the next load. Send an empty array to revoke it. **Correctness-affecting, not a hint.** If the assertion is false, a keyed mutation supersedes one version of a key and appends beside another, silently duplicating it. Declare it only where the invariant is established.
pub async fn set_database_table_constant_per_key(

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: the two new constant-per-key operations reach no wrapper in src/resources.rs (not blocking).

Callers must reach into apis::databases_api directly, while comparable operations get a wrapper — databases().lookup_by_name at src/resources.rs:198 wraps lookup_database_by_name. Consider adding databases().set_table_constant_per_key and the connection-scoped equivalent.

@claude claude Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Review

Blocking Issues

  • CHANGELOG.md:12 — the Unreleased section records only the upload doc edit. The diff also renames key_determines to constant_per_key on three request models, adds a required constant_per_key field to TableInfo, adds a JobType variant, and adds two endpoints with two models. Each rename and signature change breaks downstream compilation silently.

Action Required

  • Expand the Unreleased section to list the breaking changes with the **Breaking:** marker used at CHANGELOG.md:50, :56, :59 and :63.
  • List the new endpoints and models under an Added subsection.

Note on CI: the Check release metadata job passes here regardless. scripts/check-release.py:63 returns early while the Cargo.toml version is unchanged.

One non-blocking nit is inline on src/apis/databases_api.rs.

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.

0 participants