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

!!! TASK: Throw exceptions in unnecessary rebase and publish cases #5337

Draft
wants to merge 3 commits into
base: 9.0
Choose a base branch
from

Conversation

mhsdesign
Copy link
Member

Upgrade instructions

Review instructions

Checklist

  • Code follows the PSR-2 coding style
  • Tests have been created, run and adjusted as needed
  • The PR is created against the lowest maintained branch
  • Reviewer - PR Title is brief but complete and starts with FEATURE|TASK|BUGFIX
  • Reviewer - The first section explains the change briefly for change-logs
  • Reviewer - Breaking Changes are marked with !!! and have upgrade-instructions

bwaidelich
bwaidelich previously approved these changes Nov 1, 2024
Copy link
Member

@bwaidelich bwaidelich left a comment

Choose a reason for hiding this comment

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

You're a workhorse, thanks for taking care.
+1 by reading

@mhsdesign
Copy link
Member Author

It was @kitsunet work i downloaded the patch as i thought it would go to waste :D

@bwaidelich
Copy link
Member

It was @kitsunet work i downloaded the patch as i thought it would go to waste :D

you are both work horses 🐴 🐴

@mhsdesign
Copy link
Member Author

Okay well its not thaaaat easy ...

Following case have to be thought out:

@kitsunet
Copy link
Member

kitsunet commented Nov 4, 2024

Okay well its not thaaaat easy ...

Following case have to be thought out:

* what should happen if `nodesToPublish` is empty?

I think we could/should prevent this in the command?! If we want to throw we can decide further up front (aka UI).

* what should happen if the node id in `nodesToPublish` did not match anything?

IMHO that is a fair possibility that can happen with race conditions on shared workspaces for example, so I would handle it gracefully and accept this as no-op. BUT given next point I probably opt for exception and graceful handling further up the chain.

* what should happen on full or partial publish if there are no pending changes in the workspace?

Yeah this is the tricky case compared to the above, IF you had a race condition and send identifiers to a partial publish that are no longer changed this is similar to starting a full publish if there are no pending changes (anymore).

* what should happen on full or partial **discard** if there are no pending changes in the workspace?

Same as above I guess. If we start to throw.

* what should happen on rebase if the workspace is not outdated?

Probably again same as above.

For all of this though we should make sure there is a way out even for unexpected situations. Which could e.g. be the rebase or discard even if things look unchanged.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Status: Blocked
Development

Successfully merging this pull request may close these issues.

3 participants