fix(checkpoint-postgres): store channel_values correctly #577
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Prior to this change,
PostgresSaver
wouldn't storechannel_values
ifnewVersions
wasn't passed to theput
method. This is due to a filter check in_dumpBlobs
that checks each channel name to ensure it appears in the channel versions object prior to serializing it for storage.Upon inspecting the other
CheckpointSaver
types, I noticed thatMemorySaver
,MongoDBSaver
, andSqliteSaver
) all ignore thenewVersions
argument to theBaseCheckpointSaver.put
method, so I think this is the correct fix. From what I can see by searching references, no test code (apart from the tests this PR changes) passes thenewVersions
argument.That said, the one reference to
BaseCheckpointSaver.put
that I found in actual shipped code is inPregelLoop._putCheckpoint
(via_checkpointerPutAfterPrevious
), and this does pass thenewVersions
argument.So I have to ask, are all of the other
CheckpointSaver
implementations, and all of the existing tests implemented incorrectly, or is this the correct fix?Found this while working on #541, thanks to the
getTuple
tests (all of them failed when I wired them up toPostgresSaver
).