Scan: Implement latest RFC revision (#9)

Description

Change

Status

Removed #131 RangeScanIdFailure (throw CouchbaseException instead)

Not there before

Removed #132 RangeScanCancelled (throw RequestCanceledException instead)

Not there before

Removed ScanTerm::minimum and ScanTerm::maximum. Instead, the from and to fields of a RangeScan are optional; an absent from or to indicates the endpoint is unbounded.

Removed references to server-side implementation details that do not impact clients.

OK

Removed "reading more than one document at a time" from the list of motivations, since a range scan is not expected to perform better than getting documents by ID using the existing KV get operation.

OK

Noted that collation (using locale-specific rules for string comparison) is out of scope.

OK

Noted that all requests related to the same stream must occur on the same KV connection.

OK

Clarified ideal behavior for concurrent streams.

OK

In languages that do not support exceptions, or if throwing an exception would not be idiomatic, ScanResult MAY return dummy values for content, cas, and expiryTime if idsOnly() returns true.

NA

SDKs that apply the range scan timeout to each individual emission should omit batchTimeLimit from ScanOptions, and should always set the time limit to 90% of the client-side timeout. SDKs that handle timeouts differently should include batchTimeLimit in ScanOptions, with a default value of 0 (unlimited).

NA

Added concurrency to ScanOptions. Defaults to 1. SDKs that have not implemented concurrent scans should omit this option from ScanOptions.

OMITTED

Removed threshold logging for range scan. Removed kvScanThreshold field from the threshold logging config.

NA

Clarified that if the SDK does not have an available endpoint to dispatch a scan creation request, it should retry until an endpoint becomes available.

 

Clarified that if multiple concurrent substreams fail permanently for different reasons, the SDK arbitrarily selects one of the failures to report to the user as the cause of the overall stream failure.

 

Categorized each error condition as "Benign", "Retryable", "Retryable with special handling", "Fatal (unless sampling scan)", or "Fatal (always)".

 

Extras:

  • Added default Timeout to be 75s.

Environment

None

Gerrit Reviews

None

Release Notes Description

None

split from

Activity

Show:
Emilien Bevierre
changed the StatusJune 27, 2023 at 6:46 PM
In Progress
Closed
Emilien Bevierre
updated the ResolutionJune 27, 2023 at 6:46 PM
None
Fixed
Emilien Bevierre
updated the Issue TypeJune 27, 2023 at 6:46 PM
Bug
Improvement
Emilien Bevierre
updated the Fix versionsJune 27, 2023 at 6:46 PM
None
3.4.9
Emilien Bevierre
changed the StatusJune 27, 2023 at 6:45 PM
In Review
In Progress
Ray Cardillo
updated the SprintJune 27, 2023 at 6:10 PM
SDK22, SDK24
SDK22, SDK24, SDK26
Emilien Bevierre
changed the StatusJune 26, 2023 at 9:27 AM
In Progress
In Review
Ray Cardillo
updated the LabelsJune 22, 2023 at 8:57 PM
None
sdkapi-3.5
Emilien Bevierre
updated the DescriptionJune 14, 2023 at 1:06 PM
||Change||Status|| |Removed #131 RangeScanIdFailure (throw CouchbaseException instead)| | |Removed #132 RangeScanCancelled (throw RequestCanceledException instead)| | |Removed ScanTerm::minimum and ScanTerm::maximum. Instead, the from and to fields of a RangeScan are optional; an absent from or to indicates the endpoint is unbounded.|✅| |Removed references to server-side implementation details that do not impact clients.|OK| |Removed "reading more than one document at a time" from the list of motivations, since a range scan is not expected to perform better than getting documents by ID using the existing KV get operation.|OK| |Noted that collation (using locale-specific rules for string comparison) is out of scope.|OK| |Noted that all requests related to the same stream must occur on the same KV connection.|OK| |Clarified ideal behavior for concurrent streams.|OK| |In languages that do not support exceptions, or if throwing an exception would not be idiomatic, ScanResult MAY return dummy values for content, cas, and expiryTime if idsOnly() returns true.|NA| |SDKs that apply the range scan timeout to each individual emission should omit batchTimeLimit from ScanOptions, and should always set the time limit to 90% of the client-side timeout. SDKs that handle timeouts differently should include batchTimeLimit in ScanOptions, with a default value of 0 (unlimited).|NA| |Added concurrency to ScanOptions. Defaults to 1. SDKs that have not implemented concurrent scans should omit this option from ScanOptions.|OMITTED| |Removed threshold logging for range scan. Removed kvScanThreshold field from the threshold logging config.|NA| |Clarified that if the SDK does not have an available endpoint to dispatch a scan creation request, it should retry until an endpoint becomes available.| | |Clarified that if multiple concurrent substreams fail permanently for different reasons, the SDK arbitrarily selects one of the failures to report to the user as the cause of the overall stream failure.| | |Categorized each error condition as "Benign", "Retryable", "Retryable with special handling", "Fatal (unless sampling scan)", or "Fatal (always)".| | Extras: * Added default Timeout to be 75s.
||Change||Status|| |Removed #131 RangeScanIdFailure (throw CouchbaseException instead)|Not there before| |Removed #132 RangeScanCancelled (throw RequestCanceledException instead)|Not there before| |Removed ScanTerm::minimum and ScanTerm::maximum. Instead, the from and to fields of a RangeScan are optional; an absent from or to indicates the endpoint is unbounded.|✅| |Removed references to server-side implementation details that do not impact clients.|OK| |Removed "reading more than one document at a time" from the list of motivations, since a range scan is not expected to perform better than getting documents by ID using the existing KV get operation.|OK| |Noted that collation (using locale-specific rules for string comparison) is out of scope.|OK| |Noted that all requests related to the same stream must occur on the same KV connection.|OK| |Clarified ideal behavior for concurrent streams.|OK| |In languages that do not support exceptions, or if throwing an exception would not be idiomatic, ScanResult MAY return dummy values for content, cas, and expiryTime if idsOnly() returns true.|NA| |SDKs that apply the range scan timeout to each individual emission should omit batchTimeLimit from ScanOptions, and should always set the time limit to 90% of the client-side timeout. SDKs that handle timeouts differently should include batchTimeLimit in ScanOptions, with a default value of 0 (unlimited).|NA| |Added concurrency to ScanOptions. Defaults to 1. SDKs that have not implemented concurrent scans should omit this option from ScanOptions.|OMITTED| |Removed threshold logging for range scan. Removed kvScanThreshold field from the threshold logging config.|NA| |Clarified that if the SDK does not have an available endpoint to dispatch a scan creation request, it should retry until an endpoint becomes available.| | |Clarified that if multiple concurrent substreams fail permanently for different reasons, the SDK arbitrarily selects one of the failures to report to the user as the cause of the overall stream failure.| | |Categorized each error condition as "Benign", "Retryable", "Retryable with special handling", "Fatal (unless sampling scan)", or "Fatal (always)".| | Extras: * Added default Timeout to be 75s.
Ray Cardillo
updated the RankJune 13, 2023 at 6:37 PM
None
Ranked higher
Ray Cardillo
updated the RankJune 13, 2023 at 6:37 PM
None
Ranked higher
Ray Cardillo
updated the RankJune 13, 2023 at 6:37 PM
None
Ranked higher
Emilien Bevierre
updated the DescriptionJune 13, 2023 at 5:01 PM
||Change||Status|| |Removed #131 RangeScanIdFailure (throw CouchbaseException instead)| | |Removed #132 RangeScanCancelled (throw RequestCanceledException instead)| | |Removed ScanTerm::minimum and ScanTerm::maximum. Instead, the from and to fields of a RangeScan are optional; an absent from or to indicates the endpoint is unbounded.|✅| |Removed references to server-side implementation details that do not impact clients.|OK| |Removed "reading more than one document at a time" from the list of motivations, since a range scan is not expected to perform better than getting documents by ID using the existing KV get operation.|OK| |Noted that collation (using locale-specific rules for string comparison) is out of scope.|OK| |Noted that all requests related to the same stream must occur on the same KV connection.|OK| |Clarified ideal behavior for concurrent streams.|OK| |In languages that do not support exceptions, or if throwing an exception would not be idiomatic, ScanResult MAY return dummy values for content, cas, and expiryTime if idsOnly() returns true.|NA| |SDKs that apply the range scan timeout to each individual emission should omit batchTimeLimit from ScanOptions, and should always set the time limit to 90% of the client-side timeout. SDKs that handle timeouts differently should include batchTimeLimit in ScanOptions, with a default value of 0 (unlimited).|NA| |Added concurrency to ScanOptions. Defaults to 1. SDKs that have not implemented concurrent scans should omit this option from ScanOptions.|OMITTED| |Removed threshold logging for range scan. Removed kvScanThreshold field from the threshold logging config.|NA| |Clarified that if the SDK does not have an available endpoint to dispatch a scan creation request, it should retry until an endpoint becomes available.| | |Clarified that if multiple concurrent substreams fail permanently for different reasons, the SDK arbitrarily selects one of the failures to report to the user as the cause of the overall stream failure.| | |Categorized each error condition as "Benign", "Retryable", "Retryable with special handling", "Fatal (unless sampling scan)", or "Fatal (always)".| |
||Change||Status|| |Removed #131 RangeScanIdFailure (throw CouchbaseException instead)| | |Removed #132 RangeScanCancelled (throw RequestCanceledException instead)| | |Removed ScanTerm::minimum and ScanTerm::maximum. Instead, the from and to fields of a RangeScan are optional; an absent from or to indicates the endpoint is unbounded.|✅| |Removed references to server-side implementation details that do not impact clients.|OK| |Removed "reading more than one document at a time" from the list of motivations, since a range scan is not expected to perform better than getting documents by ID using the existing KV get operation.|OK| |Noted that collation (using locale-specific rules for string comparison) is out of scope.|OK| |Noted that all requests related to the same stream must occur on the same KV connection.|OK| |Clarified ideal behavior for concurrent streams.|OK| |In languages that do not support exceptions, or if throwing an exception would not be idiomatic, ScanResult MAY return dummy values for content, cas, and expiryTime if idsOnly() returns true.|NA| |SDKs that apply the range scan timeout to each individual emission should omit batchTimeLimit from ScanOptions, and should always set the time limit to 90% of the client-side timeout. SDKs that handle timeouts differently should include batchTimeLimit in ScanOptions, with a default value of 0 (unlimited).|NA| |Added concurrency to ScanOptions. Defaults to 1. SDKs that have not implemented concurrent scans should omit this option from ScanOptions.|OMITTED| |Removed threshold logging for range scan. Removed kvScanThreshold field from the threshold logging config.|NA| |Clarified that if the SDK does not have an available endpoint to dispatch a scan creation request, it should retry until an endpoint becomes available.| | |Clarified that if multiple concurrent substreams fail permanently for different reasons, the SDK arbitrarily selects one of the failures to report to the user as the cause of the overall stream failure.| | |Categorized each error condition as "Benign", "Retryable", "Retryable with special handling", "Fatal (unless sampling scan)", or "Fatal (always)".| | Extras: * Added default Timeout to be 75s.
Emilien Bevierre
updated the DescriptionJune 13, 2023 at 4:55 PM
||Change||Status|| |Removed #131 RangeScanIdFailure (throw CouchbaseException instead)| | |Removed #132 RangeScanCancelled (throw RequestCanceledException instead)| | |Removed ScanTerm::minimum and ScanTerm::maximum. Instead, the from and to fields of a RangeScan are optional; an absent from or to indicates the endpoint is unbounded.|✅| |Removed references to server-side implementation details that do not impact clients.| | |Removed "reading more than one document at a time" from the list of motivations, since a range scan is not expected to perform better than getting documents by ID using the existing KV get operation.| | |Noted that collation (using locale-specific rules for string comparison) is out of scope.| | |Noted that all requests related to the same stream must occur on the same KV connection.| | |Clarified ideal behavior for concurrent streams.| | |In languages that do not support exceptions, or if throwing an exception would not be idiomatic, ScanResult MAY return dummy values for content, cas, and expiryTime if idsOnly() returns true.| | |SDKs that apply the range scan timeout to each individual emission should omit batchTimeLimit from ScanOptions, and should always set the time limit to 90% of the client-side timeout. SDKs that handle timeouts differently should include batchTimeLimit in ScanOptions, with a default value of 0 (unlimited).| | |Added concurrency to ScanOptions. Defaults to 1. SDKs that have not implemented concurrent scans should omit this option from ScanOptions.| | |Removed threshold logging for range scan. Removed kvScanThreshold field from the threshold logging config.| | |Clarified that if the SDK does not have an available endpoint to dispatch a scan creation request, it should retry until an endpoint becomes available.| | |Clarified that if multiple concurrent substreams fail permanently for different reasons, the SDK arbitrarily selects one of the failures to report to the user as the cause of the overall stream failure.| | |Categorized each error condition as "Benign", "Retryable", "Retryable with special handling", "Fatal (unless sampling scan)", or "Fatal (always)".| |
||Change||Status|| |Removed #131 RangeScanIdFailure (throw CouchbaseException instead)| | |Removed #132 RangeScanCancelled (throw RequestCanceledException instead)| | |Removed ScanTerm::minimum and ScanTerm::maximum. Instead, the from and to fields of a RangeScan are optional; an absent from or to indicates the endpoint is unbounded.|✅| |Removed references to server-side implementation details that do not impact clients.|OK| |Removed "reading more than one document at a time" from the list of motivations, since a range scan is not expected to perform better than getting documents by ID using the existing KV get operation.|OK| |Noted that collation (using locale-specific rules for string comparison) is out of scope.|OK| |Noted that all requests related to the same stream must occur on the same KV connection.|OK| |Clarified ideal behavior for concurrent streams.|OK| |In languages that do not support exceptions, or if throwing an exception would not be idiomatic, ScanResult MAY return dummy values for content, cas, and expiryTime if idsOnly() returns true.|NA| |SDKs that apply the range scan timeout to each individual emission should omit batchTimeLimit from ScanOptions, and should always set the time limit to 90% of the client-side timeout. SDKs that handle timeouts differently should include batchTimeLimit in ScanOptions, with a default value of 0 (unlimited).|NA| |Added concurrency to ScanOptions. Defaults to 1. SDKs that have not implemented concurrent scans should omit this option from ScanOptions.|OMITTED| |Removed threshold logging for range scan. Removed kvScanThreshold field from the threshold logging config.|NA| |Clarified that if the SDK does not have an available endpoint to dispatch a scan creation request, it should retry until an endpoint becomes available.| | |Clarified that if multiple concurrent substreams fail permanently for different reasons, the SDK arbitrarily selects one of the failures to report to the user as the cause of the overall stream failure.| | |Categorized each error condition as "Benign", "Retryable", "Retryable with special handling", "Fatal (unless sampling scan)", or "Fatal (always)".| |
Emilien Bevierre
updated the DescriptionJune 13, 2023 at 4:52 PM
||Change||Status|| |Removed #131 RangeScanIdFailure (throw CouchbaseException instead)| | |Removed #132 RangeScanCancelled (throw RequestCanceledException instead)| | |Removed ScanTerm::minimum and ScanTerm::maximum. Instead, the from and to fields of a RangeScan are optional; an absent from or to indicates the endpoint is unbounded.| | |Removed references to server-side implementation details that do not impact clients.| | |Removed "reading more than one document at a time" from the list of motivations, since a range scan is not expected to perform better than getting documents by ID using the existing KV get operation.| | |Noted that collation (using locale-specific rules for string comparison) is out of scope.| | |Noted that all requests related to the same stream must occur on the same KV connection.| | |Clarified ideal behavior for concurrent streams.| | |In languages that do not support exceptions, or if throwing an exception would not be idiomatic, ScanResult MAY return dummy values for content, cas, and expiryTime if idsOnly() returns true.| | |SDKs that apply the range scan timeout to each individual emission should omit batchTimeLimit from ScanOptions, and should always set the time limit to 90% of the client-side timeout. SDKs that handle timeouts differently should include batchTimeLimit in ScanOptions, with a default value of 0 (unlimited).| | |Added concurrency to ScanOptions. Defaults to 1. SDKs that have not implemented concurrent scans should omit this option from ScanOptions.| | |Removed threshold logging for range scan. Removed kvScanThreshold field from the threshold logging config.| | |Clarified that if the SDK does not have an available endpoint to dispatch a scan creation request, it should retry until an endpoint becomes available.| | |Clarified that if multiple concurrent substreams fail permanently for different reasons, the SDK arbitrarily selects one of the failures to report to the user as the cause of the overall stream failure.| | |Categorized each error condition as "Benign", "Retryable", "Retryable with special handling", "Fatal (unless sampling scan)", or "Fatal (always)".| |
||Change||Status|| |Removed #131 RangeScanIdFailure (throw CouchbaseException instead)| | |Removed #132 RangeScanCancelled (throw RequestCanceledException instead)| | |Removed ScanTerm::minimum and ScanTerm::maximum. Instead, the from and to fields of a RangeScan are optional; an absent from or to indicates the endpoint is unbounded.|✅| |Removed references to server-side implementation details that do not impact clients.| | |Removed "reading more than one document at a time" from the list of motivations, since a range scan is not expected to perform better than getting documents by ID using the existing KV get operation.| | |Noted that collation (using locale-specific rules for string comparison) is out of scope.| | |Noted that all requests related to the same stream must occur on the same KV connection.| | |Clarified ideal behavior for concurrent streams.| | |In languages that do not support exceptions, or if throwing an exception would not be idiomatic, ScanResult MAY return dummy values for content, cas, and expiryTime if idsOnly() returns true.| | |SDKs that apply the range scan timeout to each individual emission should omit batchTimeLimit from ScanOptions, and should always set the time limit to 90% of the client-side timeout. SDKs that handle timeouts differently should include batchTimeLimit in ScanOptions, with a default value of 0 (unlimited).| | |Added concurrency to ScanOptions. Defaults to 1. SDKs that have not implemented concurrent scans should omit this option from ScanOptions.| | |Removed threshold logging for range scan. Removed kvScanThreshold field from the threshold logging config.| | |Clarified that if the SDK does not have an available endpoint to dispatch a scan creation request, it should retry until an endpoint becomes available.| | |Clarified that if multiple concurrent substreams fail permanently for different reasons, the SDK arbitrarily selects one of the failures to report to the user as the cause of the overall stream failure.| | |Categorized each error condition as "Benign", "Retryable", "Retryable with special handling", "Fatal (unless sampling scan)", or "Fatal (always)".| |
Ray Cardillo
updated the Epic LinkJune 13, 2023 at 2:26 PM
None
CBD-4225
Emilien Bevierre
updated the Linked IssuesJune 13, 2023 at 2:14 PM
None
This issue split from NCBC-3273
Ray Cardillo
updated the SprintJune 12, 2023 at 4:28 PM
SDK22
SDK22, SDK24
Emilien Bevierre
updated the Story PointsJune 9, 2023 at 8:44 AM
2
3
Emilien Bevierre
changed the StatusJune 9, 2023 at 8:34 AM
Open
In Progress
Emilien Bevierre
changed the StatusJune 9, 2023 at 8:34 AM
New
Open
Emilien Bevierre
created the IssueJune 9, 2023 at 8:34 AM
Fixed
Pinned fields
Click on the next to a field label to start pinning.

Details

Assignee

Emilien Bevierre

Reporter

Story Points

3

Sprint

Fix versions

Priority

Instabug

Open Instabug

PagerDuty

Sentry

Zendesk Support

Created June 9, 2023 at 8:34 AM
Updated June 27, 2023 at 6:46 PM
Resolved June 27, 2023 at 6:46 PM
Instabug