etcd3 API - v2.0.0
    Preparing search index...

    Interface IWatchCreateRequest

    interface IWatchCreateRequest {
        filters?: (FilterType | "Noput" | "Nodelete")[];
        fragment?: boolean;
        key?: Buffer<ArrayBufferLike>;
        prev_kv?: boolean;
        progress_notify?: boolean;
        range_end?: Buffer<ArrayBufferLike>;
        start_revision?: string | number;
        watch_id?: string | number;
    }
    Index
    filters?: (FilterType | "Noput" | "Nodelete")[]

    filters filter the events at server side before it sends back to the watcher.

    fragment?: boolean

    fragment enables splitting large revisions into multiple watch responses.

    key?: Buffer<ArrayBufferLike>

    key is the key to register for watching.

    prev_kv?: boolean

    If prev_kv is set, created watcher gets the previous KV before the event happens. If the previous KV is already compacted, nothing will be returned.

    progress_notify?: boolean

    progress_notify is set so that the etcd server will periodically send a WatchResponse with no events to the new watcher if there are no recent events. It is useful when clients wish to recover a disconnected watcher starting from a recent known revision. The etcd server may decide how often it will send notifications based on current load.

    range_end?: Buffer<ArrayBufferLike>

    range_end is the end of the range [key, range_end) to watch. If range_end is not given, only the key argument is watched. If range_end is equal to '\0', all keys greater than or equal to the key argument are watched. If the range_end is one bit larger than the given key, then all keys with the prefix (the given key) will be watched.

    start_revision?: string | number

    start_revision is an optional revision to watch from (inclusive). No start_revision is "now".

    watch_id?: string | number

    If watch_id is provided and non-zero, it will be assigned to this watcher. Since creating a watcher in etcd is not a synchronous operation, this can be used ensure that ordering is correct when creating multiple watchers on the same stream. Creating a watcher with an ID already in use on the stream will cause an error to be returned.