You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
// Create will add the key/value pair iff it does not exist.
func (kv *kvs) Create(ctx context.Context, key string, value []byte) (revision uint64, err error) {
v, err := kv.Update(ctx, key, value, 0)
if err == nil {
return v, nil
}
if e, err := kv.get(ctx, key, kvLatestRevision); errors.Is(err, ErrKeyDeleted) {
return kv.Update(ctx, key, value, e.Revision())
}
// Check if the expected last subject sequence is not zero which implies
// the key already exists.
if errors.Is(err, ErrKeyExists) {
jserr := ErrKeyExists.(*jsError)
return 0, fmt.Errorf("%w: %s", err, jserr.message)
}
return 0, err
}
Every call to KeyValue.delete() writes a new tombstone entry with a new revision number. If a call to delete() occurs between the check for ErrKeyDeleted finds a previously deleted key and the second call to kv.Update() above, the client gets a wrong last sequence error despite the key being tombstoned.
The JetStream protocol does not appear to have a mechanism for an atomic KV Create which avoids the client library needing to check for a delete marker.
Expected behavior
wrong last sequence is an unexpected failure for an application to receive when calling a KV method that does not have a kvLatestRevision parameter.
Observed behavior
As near as I can tell, all KV client libraries use similar logic for create():
update(expectedRevision = 0) || update(delete marker revision)
.https://github.com/nats-io/nats.go/blob/main/jetstream/kv.go#L909-L928
Every call to KeyValue.delete() writes a new tombstone entry with a new revision number. If a call to delete() occurs between the check for ErrKeyDeleted finds a previously deleted key and the second call to kv.Update() above, the client gets a
wrong last sequence
error despite the key being tombstoned.The JetStream protocol does not appear to have a mechanism for an atomic KV Create which avoids the client library needing to check for a delete marker.
Expected behavior
wrong last sequence
is an unexpected failure for an application to receive when calling a KV method that does not have akvLatestRevision
parameter.Server and client version
nats-server: 2.10.11
natscli: 0.0.35
Host environment
Mac 13.4.1 (22F82)
2.2 GHz 6-Core Intel Core i7
32 GB 2400 MHz DDR4
Intel UHD Graphics 630 1536 MB
Steps to reproduce
nats-server -js
nats kv add mybucket
while true ; do nats kv del mybucket mykey -f ; done
The text was updated successfully, but these errors were encountered: