Improve condition handling

[jochenklar]

This PR improved the way conditions are checked in the interview. Instead of checked each element and set with a seperate request, the front end collects all checks into a list and sends as POST to a new resolve endpoint. Custom prefetching allows for very fast resolving.

[coveralls]

coverage: 94.908% (+0.007%) from 94.901% — 2.4.5/fix-conditions into main

[CalamityC]

Would it make sense to early-return when payload.length === 0 to avoid an unnecessary API call?

[CalamityC]

Is that intentional? I’m wondering if overlapping resolveConditions calls could interfere with each other in pending tracking.

[MyPyDavid]

yes, me and my GPT assistant were also wondering about this, the static pendinId might make collision??

Generate a unique request id per resolveConditions() call, not a constant string.
2.
Dispatch that id in both addToPending() and removeFromPending().
3.
Carry the same id through resolveConditionsSuccess / resolveConditionsError and have the reducer ignore stale responses if a newer resolve has already started.
That solves both problems:
•
one completion no longer clears another in-flight request
•
an older response can’t overwrite newer condition state

const requestId = `resolveConditions/${Date.now()}/${Math.random()}`
dispatch(addToPending(requestId))
dispatch(resolveConditionsInit(requestId))
return ProjectApi.resolveConditions(...).then(
  (response) => {
    dispatch(removeFromPending(requestId))
    dispatch(resolveConditionsSuccess(requestId, response))
  }
)

[MyPyDavid]

to me it seems good, I also tested with the SMP (but it does not have many conditions on asingle page)

[MyPyDavid]

yes, me and my GPT assistant were also wondering about this, the static pendinId might make collision??

Generate a unique request id per resolveConditions() call, not a constant string.
2.
Dispatch that id in both addToPending() and removeFromPending().
3.
Carry the same id through resolveConditionsSuccess / resolveConditionsError and have the reducer ignore stale responses if a newer resolve has already started.
That solves both problems:
•
one completion no longer clears another in-flight request
•
an older response can’t overwrite newer condition state

const requestId = `resolveConditions/${Date.now()}/${Math.random()}`
dispatch(addToPending(requestId))
dispatch(resolveConditionsInit(requestId))
return ProjectApi.resolveConditions(...).then(
  (response) => {
    dispatch(removeFromPending(requestId))
    dispatch(resolveConditionsSuccess(requestId, response))
  }
)