mirror of
https://github.com/THU-MAIC/OpenMAIC.git
synced 2026-10-17 05:29:46 +08:00
@openmaic/generation@0.3.1
8
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 wyucandClaude Fable 5
|
4f00cf7ad6 |
feat(materials): material library manifest and id-addressed generation images (#1153 part 2) (#1168)
* feat(materials): material library manifest and id-addressed generation images (#1153 part 2) * fix(materials): library-owned references and failure-path parity (#1153 part 2) * fix(generation): resolve-then-slice vision images and close allocation leaks (#1153 part 2) * fix(generation): bound vision resolution and make library writes leak-safe (#1153 part 2) Bound the resolve-with-refill phase with an aggregate 15s budget raced against every probe plus a 3-consecutive-failure fuse — either stop strips unresolved and unprobed ids from the mapping and proceeds (text-only at worst), never failing the request. Restore the original interleaved text ordering for non-vision runs with a mapping present. Guard the library's failed-entry-write release with an ambiguous-commit re-read: release only when the entry provably does not point at the new id, keep it when the write actually landed, and prefer a recoverable leak over a dangling entry when the re-read fails. Drop the unused package export. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * chore(generation): bump @openmaic/generation to 0.3.1 (#1153 part 2) The package's inputs changed (partitionImagesForVision, resolvedVisionImages option, non-vision ordering fix); the merge-time gate requires a version bump. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Fable 5 <noreply@anthropic.com> |
||
|
wyucandClaude Fable 5
|
5a3e81c4d9 |
feat(document): ingest uploaded sources into the asset pool and extract by id (#1153 part 0) (#1154)
* feat(document): declare a version on every extractor provider (#1153 part 0) * feat(api): accept asset-id input in the extract-document route (#1153 part 0) * feat(upload): ingest selected course materials into the asset pool (#1153 part 0) * fix(document): harden asset-id extraction inputs and close upload ingest leaks (#1153 part 0) * fix(document): scope extraction fallback and harden the asset-id path (#1153 part 0) - G1: byte fallback only on pre-extraction failures; PARSE_FAILED (422/500) is surfaced without re-running the paid extractor - G2: freeze the course-material set for the duration of generate-prep (guarded add/remove + disabled toolbar affordances, session built from the click-time snapshot, belt-and-braces drain) - G3: bound the pre-generation ingest await (~15s); timed-out ingests go byte-path and their late-resolving ids are released - G4: reject non-object JSON bodies (null/array/string/number) as 400 - G5: JSON-path provider pre-validation with generic messages, generic JSON-path PARSE_FAILED/422 responses, control-char-free log values - G6: size cap enforced via identify() before resolve() materializes bytes; too_large maps to the existing 413 * fix(document): mirror provider-hint semantics on the asset-id form and freeze prep-time controls (#1153 part 0) * fix(document): keep the asset-id form's responses free of caller input (#1153 part 0) Address review findings: answer the extractor-selection failure with a generic static message on the asset-id form (the registry's interpolated message carries the caller's MIME type; multipart keeps it verbatim, both sides now pinned by tests), dedupe same-batch material additions by content fingerprint inside the pure updater, document the network-error retry exception in shouldRetryWithByteUpload's docstring, and fix a test name asserting 500 but named 400. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Fable 5 <noreply@anthropic.com> |
||
|
LING DUAN
|
2cbe4ae293 |
feat(pi): add Native Child whiteboard tools (#1152)
* feat(pi): add native whiteboard tools * style(pi): format native whiteboard tests * fix(pi): clarify whiteboard CAS handoff * fix(whiteboard): reconcile runtime projection on open |
||
|
wyuc
|
e15780835a |
feat(media): convert legacy references to allocated asset ids (#1101)
Lands epic #1007 part 2(c): the app-side reference converter, the `audioUrl` removal, and the `DSL_VERSION` bump as one delivery unit. `convertDocumentAssetRefs` walks a loaded document (slide canvases, whiteboards, video-manifest keys, speech actions) and rewrites legacy handles to allocated pool ids: placeholders and `audioId`s with local bytes are ingested, a co-present `audioUrl`/`audioId` pair collapses to one asset, a definitively dead URL converts to an emptied reference, and a transient failure keeps both handles for a later retry. Unavailable bytes leave the document untouched for a later open, and a converted document returns by identity with no writes. Conversion runs lazily on document open and at fetch time for server-generated classrooms, with conversion and the first document save sharing the per-stage document lock: once the document commits it owns every allocation, and every failure exit rolls its pass ledger back. Legacy URL probes are bounded by a per-probe timeout and a shared 60-second pass budget. `SpeechAction.audioUrl` is removed from the DSL and every consumer reads the converted shape; the server classroom generator keeps its derived-id + serving-URL pair as an explicitly typed pre-conversion transport, consumed before persistence. `DSL_VERSION` becomes 0.2.0 with the first real ladder entry, and `@openmaic/dsl` goes to 0.9.0 per the release rule. Deferred follow-ups are tracked in #1129: production principal derivation with document/asset ownership aligned, conditional document writes, and hoisting the aggregate probe budget into the export and video-timeline paths. Refs #1007 |
||
|
wyucand杨慎
|
0a10af11cf |
feat(storage): opt-in indirect asset byte egress (#1007) (#1100)
* feat(storage): add opt-in indirect asset byte egress A deployment can now opt an asset byte GET into a 302 to a short-lived signed URL when the byte layer can sign. It is off by default, and byte-for-byte unchanged when off. The byte layer gains an optional signReadUrl capability; S3AssetByteStore implements it through the new optional @aws-sdk/s3-request-presigner peer, resolved lazily exactly like the client SDK, with a signer seam mirroring the commands seam so tests can bind doubles. The signed URL pins the contract's response headers -- the media type after the renderable allowlist, the fixed disposition, and the no-store cache posture -- via S3 response-header overrides. PgAssetStore mints the URL from the same ownership-checked transactional read a direct resolve performs, so authorization still runs per read before any URL exists, and a store whose byte layer cannot sign falls back to direct bytes. The contract documents the shape and the disclosure tradeoff: a Location into a hash-keyed byte layer names the content hash, so deployments that need the no-disclosure property keep direct egress. Refs #1007 * feat(app): wire ASSET_BYTE_EGRESS into the persistence route ASSET_BYTE_EGRESS=redirect opts asset byte GETs into the storage package's indirect egress; unset, direct, or an unrecognized value keeps the default byte-for-byte behavior, with a warning for the unrecognized case. The lazy byte-store wrapper now forwards signReadUrl and answers undefined when the resolved layer has no signer, so the PostgreSQL byte column degrades to direct bytes and the S3 layer signs without the wrapper knowing which it holds. The collector path is untouched: it builds its byte store through createAssetByteStore as before and only ever calls delete. Refs #1007 * fix(storage): let the packaged client survive redirect egress Cross-review round 1 on the indirect byte egress change found two problems. A byte response that followed a redirect carries the pinned content type but no X-Asset-Revision, and HttpAssetStore required both from the same response, so every cold resolve under redirect egress failed MALFORMED_RESPONSE. The client now detects the shape once -- a redirected byte response with no revision -- latches it, and probes HEAD before each cold GET from then on, taking the label from the probe. The probe predates the download on purpose: a replacement in between labels newer bytes with an older revision, which the next revalidation detects and corrects, while the reverse order could pin stale bytes under a fresh revision with no signal to repair it. The probe doubles as the miss check, so a redirect-mode miss costs no download. The direct path is byte-for-byte unchanged; the one double download per client lifetime on first contact is documented in the contract, which gains the client-side paragraph this behavior implements. signedUrlTtlSeconds also accepted lifetimes beyond the seven-day SigV4 presigning maximum, minting redirects the object store would reject. The option is now capped at construction. Refs #1007 * fix(storage): cap signed URL lifetime below the reclamation grace A signed URL whose lifetime exceeds the collector grace period can outlive its object: the last reference goes, the grace elapses, the collector deletes the object, and the still-valid URL errors at the object store. The previous ceiling -- the seven-day SigV4 maximum -- made that window days wide against the one-hour default grace. The cap is now fifteen minutes, and the contract text states both the ceiling and the rule for deployments that shorten their grace. Refs #1007 * fix(storage): decline signing when the optional presigner is absent An unresolvable @aws-sdk/s3-request-presigner made signReadUrl throw, which the registry surfaced as a failed asset read -- a 500 for a deployment whose only fault is a missing optional peer. The contract's answer for a byte layer that cannot sign is the capability fallback: return undefined and let the caller serve the bytes directly. Signing errors from a resolved signer still fail loud; only the missing capability declines. Refs #1007 * fix(storage): answer redirect egress as a descriptor to asking clients Following a 302 is not header-neutral: the platform fetch forwards the original request's headers to the object store's origin, stripping only Authorization, so a deployment whose credential travels in a custom header would hand it to the object store -- and the preflight the forwarded custom headers provoke commonly fails there besides. This replaces the latch-and-probe client shape with an explicit one: the client sends X-Asset-Egress: descriptor on every byte GET, a redirect-egress server answers 200 with a JSON { url, revision } body instead of a Location, and the client fetches the signed URL with no deployment headers at all. The revision comes from the descriptor, so the probe-first ordering and its one wasted download are gone too. The 302 remains the answer for consumers that did not ask; the descriptor response is marked by its own header so a JSON-media asset can never parse as one. Refs #1007 * fix(storage): negotiate the descriptor through Accept, not a custom header A custom X-Asset-Egress request header is not CORS-safelisted, so every byte GET to a cross-origin server became a preflighted request -- a regression for direct-egress deployments that never opted into anything, against servers with no reason to allow the header. The negotiation now rides Accept with a vendor media type, which is safelisted and costs no preflight, and the descriptor answer is identified by that media type as its Content-Type rather than by a marker header. Refs #1007 * fix(storage): sign outside the registry transaction and reserve the descriptor type Two review findings on the indirect egress path. resolveIndirect awaited the signer inside the coordinated read, but a signer on refreshable credentials can wait on the network, and a database connection plus the blob row's FOR SHARE lock would be held across that delay. The read now closes first -- the lock still puts the hash, label and revision in one snapshot -- and signing runs afterwards, which cannot observe anything the read did not. The descriptor media type is also reserved from renderableTypes: the client identifies a descriptor answer by that exact Content-Type, and an allowlisted asset served with it would be misread as a descriptor and fail MALFORMED_RESPONSE. The handler now rejects the configuration at construction, and the contract states the reservation. Refs #1007 * fix(storage): ship the signing deps and negotiate without ambiguity Three review findings on the indirect egress path. The app now declares @aws-sdk/client-s3 and @aws-sdk/s3-request-presigner as runtime dependencies, and the standalone build force-includes them for the persistence route: both are reached through deliberately untraced dynamic imports, so the shipped image could not resolve them, and a deployment opting into S3 or redirect egress would have found the capability silently absent. The descriptor negotiation matches exactly on both sides: the client compares the Content-Type essence, so a longer media type that merely begins with the reserved value still serves as bytes, and the server parses Accept media ranges, so a descriptor range sent with q=0 selects the redirect instead of the descriptor it explicitly rejects. Refs #1007 * fix(app): refuse redirect egress when the collection grace is shorter A signed URL must never outlive its object: with the handler's 60-second default lifetime, a deployment that sets ASSET_COLLECTION_GRACE_MS below ten minutes lets the collector delete an object while a URL minted against it is still valid. The route now refuses the combination at handler initialization, naming both variables -- a deterministic misconfiguration, loud at startup rather than silent at read time. Refs #1007 * fix(app): ship the signing SDKs without loading them Two findings on the standalone deployment of redirect egress. The outputFileTracingIncludes globs did not follow pnpm's scoped symlinks, so the standalone image carried neither AWS package and both S3 mode and redirect egress could not resolve their SDK at runtime. The packages are now server-external and referenced from literal -- but never called -- dynamic import thunks in the persistence byte-store wiring, which gets them traced into the image while module resolution still happens only on first S3 use. Verified against a local standalone build: node_modules/@aws-sdk now contains both packages, and the route tests that pin the never-resolve-unless-configured discipline still pass. Media type comparisons are also case-insensitive now, as HTTP requires, on both the Accept parse and the descriptor recognition. Refs #1007 * fix(app): treat an empty collection grace as unset Number('') is 0, so a present-but-empty ASSET_COLLECTION_GRACE_MS failed the redirect-egress coordination check and took persistence down with it, while the collector's own parsing reads the same value as the one-hour default. The check now trims and treats empty as unset, matching durationEnv. Refs #1007 * fix(storage): accept bytes too, omit signing on the known-PG wrapper, state the full tradeoff Three review findings. The client's descriptor request now advertises both representations -- the vendor descriptor type preferred, */* accepted -- so a strict content-negotiating layer can never answer 406 to a client that does in fact consume plain bytes. The lazy byte-store wrapper no longer advertises signReadUrl when no bucket is configured: the layer is known to be PostgreSQL at construction, and carrying the method made resolveIndirect take its ownership query and blob-row lock just to decline, then repeat them in resolve, on every cold GET. With a bucket configured the lazy validation is preserved and the wrapper still declines when the resolved layer cannot sign. And the contract's disclosure tradeoff now states the second edge: object-store GETs carry ETag and Last-Modified, response overrides cannot strip them, and because deduplicated PUTs rewrite the hash-keyed object, Last-Modified moves when another principal re-uploads the same bytes -- shared-object write timing, beyond byte equality. Deployments for whom that signal is sensitive must keep direct egress. Refs #1007 * fix(app): degrade on bad grace, share the ttl invariant, cover the real boundary The latest review round, four findings. A misconfigured ASSET_COLLECTION_GRACE_MS now degrades redirect egress to direct with a warning instead of failing the shared handler's initialization -- the asset backend is optional, and its misconfiguration must never take document and runtime traffic down. The package exports assertSignedUrlTtlWithinGrace so a deployment wiring the handler and the collector separately validates the invariant once at its own boundary: the handler caps the lifetime, but only the deployment knows both numbers. The contract states that nosniff does not survive the redirect -- response-header overrides cannot set it -- and why the client-minted blob makes that safe for conforming clients. And the route gains a real-boundary test: the Fetch<->Node adapter, the real createStorageHttpHandler, and the egress wiring, exercised with an actual byte GET through the composed stack instead of mocks. Refs #1007 * fix(storage): make the unsafe egress configuration unrepresentable Three findings on the indirect egress path, all resolved by moving a rule into a place where it cannot be bypassed rather than by adding a check a consumer has to remember. The grace/TTL invariant now lives in the option shape. byteEgress takes 'direct' or { mode: 'redirect', collectionGraceMs, signedUrlTtlSeconds? }, so enabling indirect egress without declaring the reclamation window it lives inside no longer type-checks, and the handler validates both numbers at construction. The flat signedUrlTtlSeconds option, its cross-field "requires byteEgress redirect" check, and the standalone 900-second cap as the only guard all go away; the ceiling stays, but alongside the ratio rather than in place of it. This is what the earlier exported assertSignedUrlTtlWithinGrace could not do -- it protected only consumers who called it -- and it costs nothing in compatibility because the option is new in this branch. The app resolves the grace through one shared parser with the collector, so the number the handler checks is the number the collector runs with. A signed URL whose object is gone is now a miss. The client maps a 404 from the byte fetch to ASSET_NOT_FOUND, matching the direct path: the entry was owned and readable when the URL was minted, so a reclaimed object is the same physical state the direct read reports as a miss, and what a read means must not depend on the deployment's egress setting. Signing still does not probe for the object -- that would restore the round trip this feature removes and make the mint's price vary with prior presence -- so the contract instead requires the byte layer to answer 404 for an absent object, and states that S3 needs s3:ListBucket to do so. Route coverage now spans the whole egress matrix through the real composed handler rather than only the direct case: 302 for a consumer that did not ask, descriptor for one that did, direct bytes when the byte layer declines to sign, and direct bytes when a short grace degraded the configured mode. Refs #1007 * feat(storage): forward byte egress options through reference server * fix(storage): fail closed on redirects and unconfirmed 404s in indirect byte egress A signed-fetch 404 now maps to a miss only when the object store's XML body declares NoSuchKey; every other 404 from the signed fetch fails loud, so a wrong bucket, access point, or endpoint can no longer make a live asset read as absent. The descriptor byte GET is sent with redirect: 'manual' and any 3xx answer is treated as an error, so a server that ignores the descriptor negotiation can never forward the deployment's custom credential headers to a redirect target. The ASSET_BYTE_EGRESS switch is now documented in .env.example and the server-persistence deployment section, together with the object-store CORS and s3:ListBucket prerequisites it requires, and the asset descriptor media type is exported from the package root and the asset/http subpath. --------- Co-authored-by: 杨慎 <117187635+cosarah@users.noreply.github.com> |
||
|
|
969574bee4 |
feat(storage): wire the asset backend into the app (#1007) (#1089)
* fix(persistence): stop corrupting binary response bodies in the route adapter The embedded persistence route bridges a Node `RequestListener` to the Fetch API by hand. Its response object is cast with `as unknown as ServerResponse`, so the compiler checks none of that surface, and two parts of it were wrong in ways only a byte-carrying handler would hit. `end` decoded any `Uint8Array` chunk with `Buffer.from(chunk).toString()`, which is UTF-8. `ServerResponse.end` accepts a `Uint8Array`, and those bytes are not necessarily valid UTF-8, so every unpaired byte became U+FFFD -- silent corruption with no error anywhere. The adapter now buffers chunks as bytes and builds the response from them. `write` was absent entirely, making any chunked handler a runtime TypeError rather than a compile error. It is part of the surface this object claims to implement, so it is now implemented. Neither reaches a caller today: the document and runtime handlers only ever end with JSON strings, which took the string branch. Both are traps laid for the first handler that carries bytes. Both cases are pinned by tests that fail before this change -- the binary one on a byte comparison, the chunked one with a 500 from the TypeError. The existing adapter round-trip test, whose comment already called this the most bug-prone code in the route, covered only the string path. * feat(storage): wire the asset backend into the app (#1007) The server asset registry shipped with #1007 but was reachable from nothing: the persistence route never passed an `assetStore`, and no file under `app/`, `lib/` or `components/` imported the asset server or client modules. This connects it, additively -- no DSL change, no version bump, and no behavioural change when server persistence is off. The route now builds a `PgAssetStore` on the same pool and transaction as the document store, with `PgAssetByteStore` by default and `S3AssetByteStore` when `ASSET_S3_BUCKET` opts a deployment into it. The AWS SDK stays an optional peer, reached only through a dynamic import on that branch. The offline collector is deliberately not scheduled here, and the route says so where a reader would look for it, because leaving it unscheduled grows storage without bound and scheduling it is the deployment's decision. On the browser side the asset pool gains a single-shot configuration seam modelled on the document store's, so that with server persistence enabled the pool is an `HttpAssetStore` carrying the same auth headers as the other stores. Three browser-specific mechanisms needed decisions rather than translation: `clearAssetPool` deletes an IndexedDB database today. In server mode there is nothing local to delete, and a "clear cache" action must not remove server-side assets -- that would destroy user data from a button promising to free space. It now revokes local object URLs and closes the client, and deletes nothing remote. The cross-tab replacement broadcast is unchanged. Its job is to make another tab drop a warm object URL when the bytes behind an id change, and that need is identical in server mode. The exclusivity proof that decides whether an in-place `replace` is safe reasons over this browser only: local documents, unflushed state, and a cross-tab presence probe. In server mode those cover a strict subset of the holders, since another device can reference the same id and no probe can see it -- and asking the server who else references an id would be an existence oracle over other principals. The proof therefore returns not exclusive unconditionally in server mode, and regeneration takes the existing fork path. That is the fail-closed direction and a graceful degradation rather than a break. The development authenticator had to grow the asset principal's required `key`; without it every asset request would have been correctly denied. It derives from the same learner partition, and a principal without one still gets no asset access. The route now states plainly that this key comes from a client-supplied header, so the cross-principal isolation the asset contract describes is not in force under this authenticator -- that warning previously lived only in the auth module's own header, where nobody mounting the route would see it. * fix(storage): close three defects in the asset app wiring (#1007) **The S3 branch could not load, and isolated nothing.** The route dynamically imported the storage package's S3 byte store, but that module statically imported the AWS SDK, so merely resolving it pulled the SDK into resolution and bundling. The route then separately performed an ignored native import of the SDK from the app's own scope, which fails with ERR_MODULE_NOT_FOUND because the SDK lives under the storage workspace package -- so a deployment that set the bucket got a broken store rather than an S3 one. There is now one lazy loader in one resolution scope, the storage module no longer imports the SDK at module load, and the bucket is validated at initialization rather than treated as valid because it is non-empty. A test mocks the SDK to throw on resolution and asserts that importing the byte-store module never resolves it. **A cross-tab replacement could leave a mounted lease stale.** The broadcast handler re-resolves, and `HttpAssetStore.resolve` coalesces concurrent calls for one id onto a single in-flight request -- correct on its own, and required by the contract. Together they meant a resolve triggered by the broadcast could merge into a GET that started before the peer's replacement, return the old revision, and leave the consumer on the old URL with nothing to dislodge it. The client gains an invalidation that retires its cached snapshot and advances the per-id generation without revoking any URL already issued; `release` would have been wrong here, since the contract keeps an issued URL valid until its holder releases it. Removing the invalidation call fails the new race test. **Clearing a server-backed pool left the closed client installed.** In server mode `clearAssetPool` closed the client and returned before clearing the module singleton, so every later `getAssetPool()` handed back a closed store until a page reload happened to intervene. Only the IndexedDB deletion is skipped in server mode now; the singleton is always cleared so the next call rebuilds through the configured factory. Also adds the tests whose absence let these through: a route round-trip carrying invalid UTF-8, the SDK-resolution assertion above, the broadcast race, and reopening the pool after a clear. The earlier tests were not wrong so much as aimed past the defect -- the route test used JSON text, and the S3 test injected a loader rather than exercising the imports. * chore(storage): bump package version to 0.3.0 * fix(persistence): make the route adapter faithful where it carries bytes The embedded persistence route bridges a Node `RequestListener` to the Fetch API by hand, and its response object is cast `as unknown as ServerResponse`, so the compiler checks none of that surface. Five divergences are closed here; the first two are the ones that corrupt data, the last three were raised in review. **`end` decoded bytes as text.** It ran `Buffer.from(chunk).toString()` on a `Uint8Array` chunk, which is UTF-8, so every byte outside that encoding became U+FFFD -- silent corruption with no error anywhere. The adapter now buffers chunks as bytes. **`write` was absent**, making any chunked handler a runtime `TypeError` rather than a compile error. **`write` callbacks ran inline.** Node invokes them after the chunk is handed off. A handler that writes its next chunk from each callback therefore recursed synchronously and could overflow the stack, and a throwing callback threw in the wrong execution phase. They are now deferred. **The encoding argument was ignored.** `write(s, 'latin1')` emitted `0xc3 0xa9` where Node emits `0xe9`, corrupting the body and potentially invalidating a `Content-Length` the handler had set. Both `write` and `end` now parse their full overload set and pass the encoding through. Node's own behaviour for an invalid encoding was established by probing `ServerResponse` on Node 22 rather than assumed: it throws `ERR_UNKNOWN_ENCODING` synchronously, so the adapter validates with `Buffer.isEncoding` and lets `Buffer.from` raise the native error. **Bodyless statuses were not suppressed.** Node discards writes after `writeHead(204)` or `writeHead(304)`; this passed the buffered bytes to the Fetch `Response` constructor, which throws for those statuses, so the request became a 500 instead of the intended 204 or 304. Buffered data is now discarded for 204, 205 and 304, and for `HEAD`. None of the five reaches a caller today -- the document and runtime handlers only ever end with JSON strings. They are traps laid for the first handler that carries bytes, which is why they surfaced while wiring the asset server backend, whose byte routes hit the first two immediately. Each is pinned by a test that fails when its fix is reverted. * fix(storage): keep { client, bucket } working for the S3 byte store `S3AssetByteStoreOptions.commands` was required and the store's methods called it directly, so the published `./asset/s3-bytes` export stopped accepting the `{ client, bucket }` construction it had always taken. Anyone not going through `loadS3AssetByteStore` either failed to compile or hit an undefined command factory at runtime. Make `commands` optional. Omitted, the store resolves the AWS SDK's own command constructors through a dynamic import on its first `write` / `read` / `delete` and caches them, so `{ client, bucket }` works again. Importing the module and constructing a store still never reach the optional peer dependency: a deployment that does not select S3 never resolves it. When the SDK cannot be resolved the call rejects naming `@aws-sdk/client-s3` rather than crashing on an undefined property, and the resolution is left uncached so installing the dependency fixes an already-constructed store. The lazily bound store is run against the byte-store contract, and the new isolation tests pin both that construction does not resolve the SDK and that an unresolvable SDK is reported by name. With the break gone this branch's change to the package is additive, so the version becomes a patch above main (0.2.4 -> 0.2.5) rather than the minor it was carrying. Refs #1007 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * feat(persistence): run the asset collector in the shipped deployment `PgAssetStore.remove`, and a `replace` that changes content, only stamp `asset_blobs.unreferenced_at`. `AssetCollector.collect` is the only path that deletes anything, and the persistence route deliberately did not schedule it, on the grounds that scheduling is the deployment's decision. The deployment this repository ships is docker-compose.yml: the app and PostgreSQL, and nothing else that could make that decision. "The deployment decides" therefore meant "it never runs", and ordinary asset churn retained PostgreSQL bytes or S3 objects forever. Schedule it from instrumentation.ts, which Next runs once per server process — a route module can be instantiated more than once and has no shutdown hook, so a schedule started from one is really started per instantiation. Next 15 and later pick the file up with no config, so next.config.ts is unchanged. Collection is on by default with a 15-minute interval and the package's one-hour grace period, so the Compose stack is correct with no operator action. ASSET_COLLECTION_INTERVAL_MS, ASSET_COLLECTION_GRACE_MS, and ASSET_COLLECTION_ENABLED change or disable it, each documented where it is read. Without DATABASE_URL nothing is scheduled at all, and a failed pass is logged and retried on the next tick rather than ending the schedule or the process. Several instances may collect concurrently: each candidate blob row is re-checked and locked FOR UPDATE inside its own transaction, so collectors serialize on the row rather than racing. The comment says so, so nobody adds a distributed lock that is not needed. The byte-store selection moves to lib/persistence/asset-byte-store so the collector reclaims through the same layer the request path wrote through. A collector on the PostgreSQL byte store while the route wrote to S3 would drop the blob row and orphan the object permanently. Refs #1007 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * feat(storage): bound each collector pass and report whether it filled An unbounded collect() is sized by however long a deployment ran before collection was scheduled: one statement selecting every eligible blob, then a transaction and a byte-layer delete each, in a loop nothing interrupts. The first pass over the Compose deployment that grew a backlog before collection was scheduled is exactly that pass. A pass now takes at most batchSize blobs (default one thousand) and returns. Ordinary churn between two scheduled passes is far below the cap, so a healthy deployment behaves as it did when a pass was unbounded; a capped pass costs the remainder one scheduling interval, which is what the interval is for. collect() still answers with the count, and the count alone cannot tell an empty backlog from a full batch -- a re-referenced or concurrently taken candidate is skipped, so even a full batch can collect less than batchSize. collectPass() returns the count together with capped, which is exactly "this batch was full, run again"; a caller draining a backlog loops while it is true. Candidates are taken oldest-unreferenced first, with the content hash as tiebreaker within one timestamp. Ordering by the hash alone would starve: digests are uniformly distributed, so a high-sorting blob waits behind every lower digest stamped after it, and under steady arrivals those keep coming. The tests pin the ordering against a planner that happens to answer the right rows without an ORDER BY. Refs #1007 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(persistence): keep asset backend faults off the shared handler Two review findings on the app wiring. A concrete asset pool instance is single-lifecycle, but resolveConfiguredAssetPoolStore handed the same object out again after clearAssetPool() had closed it, reinstalling a dead store as the live pool. The second handout now refuses loudly and points at the factory form, which rebuilds on every resolution. createPersistenceHandler eagerly awaited the asset byte store, so an invalid ASSET_S3_BUCKET or an unresolvable AWS SDK rejected the shared persistence handler and took document and runtime traffic down with an optional backend. Byte-store construction is now deferred to the first asset byte operation, and a failed construction is not cached, so the next asset request retries -- the route's own no-poisoned-singleton rule. Refs #1007 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> --------- Co-authored-by: 杨慎 <117187635+cosarah@users.noreply.github.com> Co-authored-by: Claude Opus 5 <noreply@anthropic.com> |
||
|
wyucand杨慎
|
28ea48bba9 |
fix(storage): omit undefined object fields at persistence boundaries (#992)
* fix: canonicalize optional persistence fields * fix: preserve document store method receivers * fix: support immutable document stores * fix: align persistence equality checks * test: reset document store wrappers * fix: normalize injected migration stores --------- Co-authored-by: 杨慎 <117187635+cosarah@users.noreply.github.com> |
||
|
wyucandCodex
|
e39c64cd9e |
feat(persistence): one-command server-backed stack (compose profile + embedded API + docs) (#982)
* feat(persistence): one-command server-backed stack — embedded API + compose postgres profile docker compose --profile server-persistence up --build runs exactly two containers: the app (persistence HTTP server embedded at /api/persistence, enabled only when DATABASE_URL is set — unset keeps today's browser-only behavior byte-for-byte) and PostgreSQL 16. Client bootstrap configures both storage seams against the same-origin route when NEXT_PUBLIC_PERSISTENCE=1, riding the existing lazy migrations so prior browser data reaches the server per-course on first open. Dev auth (bearer token + client-asserted learner header) lives in one overridable module and is loudly documented as development-grade. Verified end-to-end against the real stack: document PUT/GET and runtime session create land in Postgres; bad tokens 401. Co-authored-by: Codex <codex@openai.com> * fix(persistence): review round — structural bootstrap ordering, retryable init, honest failure surfaces The bootstrap side-effect import moves into the two storage seam entry modules, so any module graph that can resolve a store necessarily evaluates it first — no client-entry ordering luck, and the two configure calls are all-or-nothing. A failed server init clears its cached promise (next request retries instead of permanent 500s). listStages rethrows backend failures and the dashboard surfaces a persistence-unavailable error instead of rendering an empty list that reads as data loss. Docs state the build-time nature of NEXT_PUBLIC_PERSISTENCE, the real token boundary (any visitor can extract it and impersonate any learner — localhost/trusted-network only), and the correct postgres password rotation. Dev-token compare is timing-safe; the handler singleton lives on globalThis so HMR cannot leak pools. Co-authored-by: Codex <codex@openai.com> * fix(persistence): review response — no-confidentiality wording + adapter round-trip coverage The token docs now state plainly that the NEXT_PUBLIC token is compiled into the public bundle and provides no confidentiality or user isolation (its only role is keeping unrelated scanners off a trusted network). The Fetch/Node adapter — the route's most bug-prone code — gains a round-trip integration test: PUT body streaming, 201 with multi-value headers, 204 empty body, and encoded path segments reaching the handler un-decoded. --------- Co-authored-by: Codex <codex@openai.com> |