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

ShellScope RegisterBeforeDispose should support sequential inserts #16306

Closed
deanmarcussen opened this issue Jun 12, 2024 · 3 comments · Fixed by #16322
Closed

ShellScope RegisterBeforeDispose should support sequential inserts #16306

deanmarcussen opened this issue Jun 12, 2024 · 3 comments · Fixed by #16322
Milestone

Comments

@deanmarcussen
Copy link
Member

Describe the bug

ShellScope.RegisterBeforeDispose currently does this

internal void BeforeDispose(Func<ShellScope, Task> callback) => _beforeDispose.Insert(0, callback);

inserting the added callback at position zero in the list.

if using multiple RegisterBeforeDispose in a shell scope, it would be useful if you could actually insert a callback at the end of the list, rather than always at the beginning.

We have a number of tasks which need to be deferred till after the session has been disposed (mostly signalr events, which then trigger callbacks to read commited data), but they need to happen in the correct sequence, where inserting them at the start breaks the sequence.

An overload that supported _beforeDispose.Add(callback); would be ideal.

@gvkries
Copy link
Contributor

gvkries commented Jun 13, 2024

You can always insert in reverse order, but it doesn't seem necessary to insert at the start in general as the order cannot be guaranteed anyways in regards to multiple call sites.

@sebastienros
Copy link
Member

Let's add a new overload void BeforeDispose(Func<ShellScope, Task> callback, bool last) that will populate a _beforeDisposeLate collection (lazily initialized) with a _beforeDisposeLate.Add call instead. This way we don't break the current behavior, and you can register specifically at the end of everything. Noting that you won't still be able to manage exactly when compared to other callbacks in the same bucket.

@sebastienros sebastienros added this to the 2.x milestone Jun 13, 2024
Copy link
Contributor

We triaged this issue and set the milestone according to the priority we think is appropriate (see the docs on how we triage and prioritize issues).

This indicates when the core team may start working on it. However, if you'd like to contribute, we'd warmly welcome you to do that anytime. See our guide on contributions here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants