-
Notifications
You must be signed in to change notification settings - Fork 547
Write support for blob handles with pending payload #24458
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull Request Overview
This PR ports write support for blob handles with pending payload by adding a new flag (createBlobPayloadPending) and updating tests, API signatures, and internal handling of blob payload states. Key changes include:
- Updating test files to run with and without pending payload support.
- Adding new type guards and API exports (e.g. isFluidHandlePayloadPending) to support pending payload states.
- Updating blob manager logic to handle payload state transitions (local, shared, failed).
Reviewed Changes
Copilot reviewed 13 out of 13 changed files in this pull request and generated 1 comment.
Show a summary per file
File | Description |
---|---|
packages/test/test-end-to-end-tests/src/test/blobsisAttached.spec.ts | Refactored imports and wrapped tests in a loop for createBlobPayloadPending variations. |
packages/test/test-end-to-end-tests/src/test/blobs.spec.ts | Updated test container config and test descriptions to pass the new flag. |
packages/runtime/runtime-utils/* | Export and add new type guard for handling pending blob payloads. |
packages/runtime/container-runtime/src/* | Updated blob manager methods and tests to support blob handles with pending payloads. |
packages/common/core-interfaces/* | Added new interfaces and types for the pending payload feature. |
packages/runtime/container-runtime/src/test/blobManager.spec.ts
Outdated
Show resolved
Hide resolved
Co-authored-by: Copilot <[email protected]>
🔗 No broken links found! ✅ Your attention to detail is admirable. linkcheck output
|
* @legacy | ||
* @alpha | ||
*/ | ||
export type PayloadState = "local" | "shared" | "pending" | "failed"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i'm trying to think through the usage here. what are the supported state transitions? how do users reason about them? What is the experience for local client vs remote clients? are they symmetrical? should they be, or do client need custom code for local and remote.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i think this would be easier to review if the implementation were split from api, as the api will likely have significantly more comments than the internals. getting the internals in would also unblock re-enabling testing with staging mode.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i think we should remove 'local' at this layer, and only have "persisted" | "pending" | "failed"
, anything related to local should be moved to a blob handle type such that local information is only available on the strongly typed local object returned from the call to upload.
(event: "shared", listener: () => void); | ||
/** | ||
* Emitted for locally created handles when the payload fails sharing to remote collaborators. | ||
*/ | ||
(event: "failed", listener: (error: unknown) => void); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i think we should remove both of these, and just have a single event for progress. Maybe something like:
(event: "progress", listener: ({type:"update"} | {type:"persisted"} | {type:"failed" error?:Error})=>void)
this ensure the event is applicable to all clients, and it lets the handle implementation short-circuit the event if someone registers while the state is already terminal (persisted or failed). we do this for a number of events like connected, as we saw users frequently building dangling event handles that never resolved as the connection state was already connected.
something like progress is probably optional for now, but someday i could see us using signals in the blob manager so broadcast progress updates.
{ | ||
private attached: boolean = false; | ||
|
||
public get isAttached(): boolean { | ||
return this.routeContext.isAttached && this.attached; | ||
} | ||
|
||
private readonly _events = new TypedEventEmitter<IFluidHandlePayloadPendingEvents>(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i have some concerns about memory usage. a simple callback would be much cheaper in terms of memory, especially as we don't think will be used very often, as after a handle is in a terminal state there will never be a need to listen to events again
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
another middle ground option would be to lazily initialize the TypedEventEmitter, so it only exists when it is accessed. emission would need to change to not create it if it doesn't already exist
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will look at options here. I was also thinking I should probably look at switching to the new Tree emitter too.
Ports the remainder of the prototype in #24158, which is write support for blob handles with pending payload.
Mostly unchanged as compared to the prototype, other than updating for the renames taken in #24320.
AB#36251