Stephan BehnkeandGitHub a15204553b Clear workflow contexts on History Shard closure (#6090) ...

## What changed?
<!-- Describe what has changed in this PR -->

Clear all workflow contexts, found in the cache, that belong to a
History Shard that is being closed.

## Why?
<!-- Tell your future self why have you made these changes -->

Right now, when a History Shard is closed, any non-durable Update that
is still in-flight will be "lost", meaning that there is no way to
access it, cancel it or complete it anymore. The client that issued the
Update is not informed about this either (neither is the Frontend).

A better experience is to forcibly cancel any in-flight Updates
belonging to the History Shard that is closing. That way, the Frontend
can re-issue the Update request (which will land on a new History
Shard). The client won't even know that the History Shard was closed.
However, if the retry happens towards the end of the Update timeout, the
client's request might still time out after all.

## How did you test it?
<!-- How have you verified this change? Tested locally? Added a unit
test? Checked in staging env? -->

Added unit tests and functional test.

Before going live, this will have to be validated by thorough end-to-end
testing.

## Potential risks
<!-- Assuming the worst case, what can be broken when deploying this
change to production? -->

### Code Complexity

Since the workflow cache already has all the workflow contexts, I had
considered adding a by-shardID index a method to iterate over them
there. However, its cache implementation is based on `cache.Cache` (ie a
generic cache) it would have been awkward to add it there. Therefore, I
decided to track the workflow contexts in a separate place, the
Finalizer, which adds to the complexity.

### Memory Leak

There is no way to list the workflow contexts that belong to a History
Shard. Therefore, a new "Finalizer" was introduced that maintains a list
of cleanup callbacks: one callback per workflow context, grouped by
History Shard.

But since the workflow cache will eventually evict workflow contexts
that are no longer needed, if the Finalizer holds on to these cleanup
callbacks past the lifetime of the workflow context, the GC won't be
able to free them from memory. Therefore, a lifecycle hook was
introduced that removes any expired workflow contexts from the
Finalizer.

### Delayed History Shard Closure

The step to close the History Shard should not lock up if some/any of
the workflow contexts cannot be cleared. To clear them, the lock for the
workflow needs to be obtained. To prevent this from blocking
indefinitely, a timeout was introduced. It's better to make sure the
History Shard closes eventually than to clear all workflow contexts.

PS: Logging has been added to be able to monitor the timeouts and
completion rate of the Finalizer.

PPS: If any production issues should occur, the Finalizer's cleanup step
can be disabled entirely by setting the dynamic config for the timeout
to zero. However, the registering/de-registering of callbacks cannot be
disabled.

## Documentation
<!-- Have you made sure this change doesn't falsify anything currently
stated in `docs/`? If significant
new behavior is added, have you described that in `docs/`? -->

## Is hotfix candidate?
<!-- Is this PR a hotfix candidate or does it require a notification to
be sent to the broader community? (Yes/No) -->

2024-07-16 18:07:31 -07:00

..

resource_dedup_test.go

Move task definition from persistence layer to business logic layer (#1983)

2021-09-27 14:42:57 -07:00

resource_dedup.go

Move task definition from persistence layer to business logic layer (#1983)

2021-09-27 14:42:57 -07:00

workflow_key.go

Clear workflow contexts on History Shard closure (#6090)

2024-07-16 18:07:31 -07:00