Skip to content
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

[WIP] Decoupling concurrency guarantees/behavior on existing invocation id in invocation request #2393

Open
wants to merge 5 commits into
base: main
Choose a base branch
from

Conversation

slinkydeveloper
Copy link
Contributor

Proposal for #2326

@slinkydeveloper slinkydeveloper changed the title Proposal of concurrency guarantees/behavior on existing invocation id semantics decoupling in invocation request [WIP] Proposal of concurrency guarantees/behavior on existing invocation id semantics decoupling in invocation request Dec 9, 2024
@slinkydeveloper slinkydeveloper changed the title [WIP] Proposal of concurrency guarantees/behavior on existing invocation id semantics decoupling in invocation request [WIP] Decoupling concurrency guarantees/behavior on existing invocation id in invocation request Dec 9, 2024
Copy link
Contributor

@tillrohrmann tillrohrmann left a comment

Choose a reason for hiding this comment

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

Thanks for sharing the progress regarding decoupling the concurrency behavior with us. It looks good to me. I've left some very minor comments.

crates/types/src/invocation.rs Outdated Show resolved Hide resolved
crates/types/src/invocation.rs Outdated Show resolved Hide resolved
crates/types/src/invocation.rs Outdated Show resolved Hide resolved
crates/types/src/invocation.rs Outdated Show resolved Hide resolved
MaxParallelism,
/// Use the default from the target semantics
#[default]
UseTargetDefault,
Copy link
Contributor

Choose a reason for hiding this comment

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

It's unclear what the default means here. It might be worth adding a couple of words to explain that it'll use the default behavior based on the target type (virtual object, service, etc.)

Also, see my note below.

inbox_key: ByteString,
},
/// No queueing, just execute the request
MaxParallelism,
Copy link
Contributor

Choose a reason for hiding this comment

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

If the previous one becomes Sequential, then this can be Concurrent


/// Behavior when sending an invocation request and the request already exists.
#[derive(Debug, Default, Clone, PartialEq, Eq, serde::Serialize, serde::Deserialize)]
enum BehaviorOnExistingInvocationId {
Copy link
Contributor

Choose a reason for hiding this comment

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

suggestion: IfExists might be a reasonable option if you like it. I can already imagine the call-site being invocation::IfExists::Attach

Comment on lines 320 to 321
#[default]
UseTargetDefault,
Copy link
Contributor

Choose a reason for hiding this comment

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

I'm not sure I like having the default variant. It adds cognitive overhead. It sounds like "it depends". An alternative strategy is to always set it on the caller-side, I suppose.

Copy link
Contributor Author

@slinkydeveloper slinkydeveloper Dec 11, 2024

Choose a reason for hiding this comment

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

it is "it depends" really :D

The reason i was thinking about introducing UseTargetDefault is for backward compatibility, and eventually i guess we remove it. The idea is that next release will act on this new two types and their variants, but we never write it, while the release afterward will also write those fields.

Also i tried to make clear the "it depends" adding the method below "infer target default"


/// Key to use for idempotent request. If none, this request is not idempotent, or it's a workflow call. See [`InvocationRequestHeader::is_idempotent`].
/// This value is propagated only for observability purposes, as the invocation id is already deterministic given the invocation id.
pub idempotency_key: Option<ByteString>,
Copy link
Contributor

Choose a reason for hiding this comment

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

does that need serde(default)?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

this field is not new, i just moved it to the bottom here.

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.

3 participants