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

Cleanup OutboxMessage abstraction #2484

Open
slinkydeveloper opened this issue Jan 13, 2025 · 1 comment
Open

Cleanup OutboxMessage abstraction #2484

slinkydeveloper opened this issue Jan 13, 2025 · 1 comment
Labels

Comments

@slinkydeveloper
Copy link
Contributor

slinkydeveloper commented Jan 13, 2025

The OutboxMessage is simply a subset of Command, it's an abstraction we don't really need and right now it's even using different serialization formats, potentially causing issues and requiring more code to be written. We should at least align the serialization of the two, or just plain remove OutboxMessage as it's not really useful to be a separate abstraction.

@slinkydeveloper
Copy link
Contributor Author

slinkydeveloper added a commit to slinkydeveloper/restate that referenced this issue Jan 14, 2025
* Add JournalTableV2, used for the new service protocol
* Expand InvocationStatus to hold, in the suspended state the _awaiting on notification_ information
* Add OutboxMessage::NotifySignal (this change is a bit pointless, see restatedev#2484)
slinkydeveloper added a commit to slinkydeveloper/restate that referenced this issue Jan 16, 2025
* Add JournalTableV2, used for the new service protocol
* Expand InvocationStatus to hold, in the suspended state the _awaiting on notification_ information
* Add OutboxMessage::NotifySignal (this change is a bit pointless, see restatedev#2484)
slinkydeveloper added a commit to slinkydeveloper/restate that referenced this issue Jan 17, 2025
* Add JournalTableV2, used for the new service protocol
* Expand InvocationStatus to hold, in the suspended state the _awaiting on notification_ information
* Add OutboxMessage::NotifySignal (this change is a bit pointless, see restatedev#2484)
slinkydeveloper added a commit to slinkydeveloper/restate that referenced this issue Jan 24, 2025
* Add JournalTableV2, used for the new service protocol
* Expand InvocationStatus to hold, in the suspended state the _awaiting on notification_ information
* Add OutboxMessage::NotifySignal (this change is a bit pointless, see restatedev#2484)
slinkydeveloper added a commit that referenced this issue Jan 24, 2025
* [types] New Journal Data model.

This contains the materialized data model `Entry` and the stored data model `RawEntry`

* [old service protocol] Fix materialization of input entry.

* [old service protocol] Add Protocol V4 manually to protobuf. We should not update this protobuf anymore

* [old/new protocol] Move (old) AwakeableIdentifier in restate_types, Introduce new ExternalSignalIdentifier used to complete awakeables created by journals using journal table V2.

* [wal protocol] Add new commands used by new service protocol.

* [ingress-http] Support the new ExternalSignalIdentifier

* [storage] Use ad-hoc type PromiseResult in PromiseTable

* [new service protocol] Introduce service-protocol-v4 crate. This crate contains the entry codec and the message codec of the new service protocol.

To simplify code generation, I also moved in a parent directory the service-protocol. Eventually we use this directory as ground truth of the protocol, and we sunset https://github.com/restatedev/service-protocol

* [storage] New tables and changes to existing ones:

* Add JournalTableV2, used for the new service protocol
* Expand InvocationStatus to hold, in the suspended state the _awaiting on notification_ information
* Add OutboxMessage::NotifySignal (this change is a bit pointless, see #2484)

* [invoker] Add service protocol V4 support.

* This adds few new effects, such as JournalEntryV2 and SuspendedV2 to carry the new journal info.
* The ServiceProtocolRunnerV4 is a copy of the previous ServiceProtocolRunner, but using the new message and entry types. There is no respective EntryEnricher for Journal V2, as it was a useless abstraction.
* The JournalReader interface can read both the old and the new journal. If the service protocol uses version 4, an in-flight migration of the input entry is executed by the ServiceProtocolRunnerV4
* Few changes were needed in the InvocationStateMachine to support the new cases to wait for retries, notably if we propose a run completion, then we need to wait for that to be pushed in the journal before retrying.

* [state machine] Add new actions needed to interact with the invoker using protocol v4

* [old state machine] Many changes:

* Changes all the receivers to receive on StateMachineContext with self. This helps the new state machine for now, albeit we should remove all these methods in future.
* Added branching points with new state machine.

* [new state machine] CommandHandlers for entries

* [new state machine] CommandHandlers for lifecycle events

* [service protocol wireshark dissector] Support service protocol v4

* Assorted irrelevant changes related to renamings and friends.

* [new state machine] Add some unit tests + fix bugs

* [old state machine] Make sure you can complete protocol V4 awakeables from protocol V3

* [datafusion] Wire journal table V2

* Rebase

* Remove unused files. This avoids confusion updating the wrong file.

* Remove unused files. This avoids confusion updating the wrong file.

Other few finishing touches.

* Fix lil back-compat issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant