-
Notifications
You must be signed in to change notification settings - Fork 549
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
Changes from 7 commits
34eac3e
f715d3a
6f7beca
6510b24
5e8872d
854d288
aff9689
9770df6
142aebb
b280f92
dff0849
b100d89
29a334c
9d24881
a93261f
516f2d7
0c78871
7021f99
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -4,6 +4,7 @@ | |
*/ | ||
|
||
import type { ErasedType } from "./erasedType.js"; | ||
import type { IEvent, IEventProvider } from "./events.js"; | ||
import type { IRequest, IResponse } from "./fluidRouter.js"; | ||
|
||
/** | ||
|
@@ -117,6 +118,52 @@ export interface IFluidHandleInternalPayloadPending< | |
readonly payloadPending: boolean; | ||
} | ||
|
||
/** | ||
* The state of the handle's payload. | ||
* - "local" - The payload is only available to the local client, and not to remote collaborators | ||
* - "shared" - The payload is availabe to both the local client and remote collaborators | ||
* - "pending" - The payload is not yet available to the local client | ||
* - "failed" - The payload is available to the local client but has failed in sharing to remote collaborators | ||
* @legacy | ||
* @alpha | ||
*/ | ||
export type PayloadState = "local" | "shared" | "pending" | "failed"; | ||
|
||
/** | ||
* Events which fire as the handle's payload state transitions. | ||
* @legacy | ||
* @alpha | ||
*/ | ||
export interface IFluidHandlePayloadPendingEvents extends IEvent { | ||
/** | ||
* Emitted when the payload becomes available to all clients. | ||
*/ | ||
(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 commentThe 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: 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. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I hesitate to merge since the customer reaction to a failure likely has no overlap with their reaction to successful completion. In general it's more ergonomic for a customer to register specifically for the event they're interested in observing (rather than forcing them to conditionalize within their handler). The short-circuiting behavior you mention is an antipattern, we removed many of those over time (e.g. #14371, not sure if we got them all though). See #14272 (comment) and other comments in that PR for more context. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. i find it more ergonomic to only need a single event when both events must always be considered, as i don't think there is ever a case where shared or failed are useful separately, so the current design forces a complicated multi event pattern. if there is a single event pattern, combining also doesn't make that more difficult. |
||
} | ||
|
||
/** | ||
* Observable state on the handle regarding its payload sharing state. | ||
* | ||
* @privateRemarks | ||
* Contents to be merged to IFluidHandle, and then this separate interface should be removed. | ||
* @legacy | ||
* @alpha | ||
*/ | ||
export interface IFluidHandlePayloadPending<T> extends IFluidHandle<T> { | ||
/** | ||
* The current state of the handle's payload. | ||
*/ | ||
readonly payloadState: PayloadState; | ||
/** | ||
* Event provider, with events that emit as the payload state transitions. | ||
*/ | ||
readonly events: IEventProvider<IFluidHandlePayloadPendingEvents>; | ||
} | ||
|
||
/** | ||
* Symbol which must only be used on an {@link (IFluidHandle:interface)}, and is used to identify such objects. | ||
* | ||
|
Uh oh!
There was an error while loading. Please reload this page.
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.
Uh oh!
There was an error while loading. Please reload this page.
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.
Uh oh!
There was an error while loading. Please reload this page.
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.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.
For visibility - had a chat with Tony on the side, we have a bit better understanding of each other now.
Re: the question above, the states are not symmetrical for local/remote nor should they be, since the states are wholly different between the two (both in what can be detected and what reaction should be taken), with the exception of "shared" state which is where they reach parity. I've updated the documentation a bit to clarify as well.
In our conversation Tony suggested splitting the interface instead, such that local/remote have different types. I'm thinking more on this option or if there's any preferable alternative here.
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.
Also just realized that you can use mermaid diagrams in github comments, so including the current state diagram here too:
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 understand the remote case a bit better now, but i'm still not sure the api as is ergonomic for the remote case
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.
Re: splitting the interface, I'm struggling to find a case where it improves the customer experience.
When creating a BlobHandle via uploadBlob(), the customer immediately gets the handle back in local state (and it will not exit this state until they elect to attach the handle, giving them plenty of time to register listeners). They need the full interface except "pending" state, since they likely want to observe all of the possible transitions and states through the upload process. It's true we have type knowledge here that the handle will never enter "pending" state, but at the same time the customer doesn't need to do anything special to avoid the "pending" state; it doesn't get in their way.
To acquire a RemoteFluidObjectHandle, the customer is likely pulling it from a location where it might be mixed in with BlobHandles in normal app operation. For example, if I get an IFluidHandle out of a SharedMap it is probably dangerous to assume whether that IFluidHandle is actually a BlobHandle or RemoteFluidObjectHandle. The customer can't ignore that both are possibilities with whatever logic they're applying. However, I don't think this is a burden for them. If we assume they are doing their local failure watching at the point of calling uploadBlob as suggested above, then this portion is probably just looking to run the remote cleanup heuristic.
These are obviously just examples, but I don't see where having a narrower interface necessarily simplifies. If there are other better examples would be glad to take a look though.
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.
Sorry I just realized I had missed your tsplayground - responses inline here
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.
based on the responses i feel pretty strongly we should split the local and remote experiences. its very confusing that only some states and events only apply local or remote. I can see customer writing code where they wait for failure on remote handles which is impossible, but nothing in the interface or code will prevent it. I'm of the opinion that when possible, it should be clear from the code itself how to use an api, and it seems quite achievable here with little change.
for the local api, i would still push for a combined event which covers both shared and failed states to avoid the need to write code that crosses event handles, as that type of code gets very complex, especially when you take in further requirements like tracking close/dispose to give up.
I'm also curious what @yann-achard-MS and @znewton think about this, as they will helping partners to onboard these apis and their extensions.
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 would also consider punting on the remote half of the api, since its not hooked up yet, so no need to commit to that api yet anyway.