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

Incompatible with django-fsm and it's ConcurrentTransitionMixin #578

Open
pfcodes opened this issue Jul 11, 2024 · 1 comment
Open

Incompatible with django-fsm and it's ConcurrentTransitionMixin #578

pfcodes opened this issue Jul 11, 2024 · 1 comment
Labels
bug Something isn't working question Further information is requested

Comments

@pfcodes
Copy link

pfcodes commented Jul 11, 2024

Strawberry GraphQL has weird behavior when DjangoOptimizerExtension is enabled and its resolving objects based on django models that inherit ConcurrentTransitionMixin from the django-fsm package.

Resolving one type resulted in a RecursionError: maximum recursion depth exceeded error. Another type triggered a Direct state modification not allowed error.

From the ConcurrentTransitionMixin docs:

"""
Protects a Model from undesirable effects caused by concurrently executed transitions,
e.g. running the same transition multiple times at the same time, or running different
transitions with the same SOURCE state at the same time.

This behavior is achieved using an idea based on optimistic locking. No additional
version field is required though; only the state field(s) is/are used for the tracking.
This scheme is not that strict as true *optimistic locking* mechanism, it is however
more lightweight - leveraging the specifics of FSM models.

Instance of a model based on this Mixin will be prevented from saving into DB if any
of its state fields (instances of FSMFieldMixin) has been changed since the object
was fetched from the database. *ConcurrentTransition* exception will be raised in such
cases.

For guaranteed protection against such race conditions, make sure:
* Your transitions do not have any side effects except for changes in the database,
* You always run the save() method on the object within django.db.transaction.atomic()
block.

Following these recommendations, you can rely on ConcurrentTransitionMixin to cause
a rollback of all the changes that have been executed in an inconsistent (out of sync)
state, thus practically negating their effect.
"""

Graphene doesn't behave in this way. Would love to be able to migrate over to Strawberry without losing the benefits of the `ConcurrentTransitionMixin`

Upvote & Fund

  • We're using Polar.sh so you can upvote and help fund this issue.
  • We receive the funding once the issue is completed & confirmed by you.
  • Thank you in advance for helping prioritize & fund our backlog.
Fund with Polar
@pfcodes pfcodes added the bug Something isn't working label Jul 11, 2024
@pfcodes pfcodes closed this as completed Jul 11, 2024
@pfcodes pfcodes reopened this Jul 11, 2024
@bellini666
Copy link
Member

Hi @pfcodes ,

Hrm, that's interesting... Wondering what might be causing it.

Can you share more details about that, like the traceback you get?

@bellini666 bellini666 added the question Further information is requested label Jul 11, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants