Support passing headers in calls #17
Conversation
jackkleeman
force-pushed
the
headers
branch
2 times, most recently
from
9fe6871 to
76c6872
Compare
| Codec encoding.Codec | ||
| Headers map[string]string |
There was a problem hiding this comment.
Just curiosity, could you infer the content-type header from Codec? Maybe we can have an CodecWithContentType ducktype too...
There was a problem hiding this comment.
That's basically what a payload codec is. Yes we could maybe make this a payload codec field and set content type this way
There was a problem hiding this comment.
hmm, its backwards incompatible to start adding a field to the headers unless we specifically exclude it from non-determinism comparisons. caution required. one wonders if it should even be a separate field in the call entries?
There was a problem hiding this comment.
hmm, its backwards incompatible to start adding a field to the headers unless we specifically exclude it from non-determinism comparisons.
This change, like every addition to the protocol/sdk, indeed requires a minor version bump (in the 1.x schema, but same with 0.x i guess), to notify the user that when bumping the sdk, they need to re-register again as protocol specifics might change. This is a general rule that applies.
Requires runtime support: restatedev/restate#1741