Caching error on cancel saving operation

When cancelling an operation in the ContentService.Saving event the content will not be saved in the database (or in the Examine index), but the Umbraco backoffice still shows the unsaved value even after a page reload. Only a restart of the site will bring back the original saved value. This means that editors believe the new value is saved even though they get an error message.

Umbraco version

I am seeing this issue on Umbraco version: 8.6.3

Reproduction

1. Clean Umbraco 8.6.3 project
2. Created a single document type with a single property of type textstring
3. Added the following component:

[RuntimeLevel(MinLevel = RuntimeLevel.Run)]
public class SavingEventComposer : ComponentComposer<SavingEventComponent>
{
}

public class SavingEventComponent : IComponent
{
    public void Initialize()
    {
        ContentService.Saving += ContentService_Saving;
    }

    private void ContentService_Saving(IContentService sender, ContentSavingEventArgs e)
    {
        foreach (var entity in e.SavedEntities)
        {
            if(entity.GetValue<string>("text") == "Value to cancel saving")
            {
                e.CancelOperation(new EventMessage("Cancel saving event", "The saving event has been cancelled", EventMessageType.Error));
            }
        }
    }

    public void Terminate()
    {
    }
}

1. Adding the value of “test” in the text field - > save is successfull
2. Changing the value to “Value to cancel saving” in the text field -> an error message is showing and the value is not saved in the database, but the text field still shows the new value “Value to cancel saving”
3. Restart the website and text field now correctly shows first value og “test”

Expected result

When cancelling a saving event the UI should after a reload show the original/saved value

Actual result

Even after a reload of the page the UI still shows the unsaved value (properbly from a cache?), only after a restart of the website the UI will show the original/saved value.

[nul800sebastiaan]

@jesperweber Aaaah… 💡 Lightbulb moment!

I see what you mean now. Yep, that would be great.

To be honest, I have no idea how this currently works in the sense that the data is not saved in the database but somehow persisted for the editor until an app pool recycle, that seems interesting.

If any of you would like to sink their teeth into that one and figure out if the desired scenario can be made possible then that would be great. I imagine it might require quite a bit of work, so let’s first get an overview of how it can be done before work starts on it, that way I can get someone at HQ to say: “yes, good solution” or “no, we should probably fix it like…x”.

[umbrabot]

Hiya @jesperweber,

Just wanted to let you know that we noticed that this issue got a bit stale and might not be relevant any more.

We will close this issue for now but we’re happy to open it up again if you think it’s still relevant (for example: it’s a feature request that’s not yet implemented, or it’s a bug that’s not yet been fixed).

To open it this issue up again, you can write @umbrabot still relevant in a new comment as the first line. It would be super helpful for us if on the next line you could let us know why you think it’s still relevant.

For example:

@umbrabot still relevant This bug can still be reproduced in version x.y.z

This will reopen the issue in the next few hours.

Thanks, from your friendly Umbraco GitHub bot 🤖 🙂