Details
-
Bug
-
Status: Resolved
-
Major
-
Resolution: Fixed
-
None
-
None
-
DOC-2021-Feb28-S4, DOC-2021-Mar14-S5, DOC-2021-Mar28-S6, DOC-2021-Apr11-S7, DOC-2021-Apr25-S8, DOC-2021-May09-S9, DOC-2021-May23-S10, DOC-2021-Jun06-S11, DOC-2021-Jun20-S12, DOC-2021-Jul04-S13, DOC-2021-Jul18-S14, DOC-2021-Aug01-S15, DOC-2021-Aug15-S16, DOC-2021-Aug29-S17, DOC-2021-Sep12-S18, DOC-2021-Sep26-S19, DOC-2021-Oct10-S20, DOC-2021-Oct24-S21, DOC-2021-Nov07-S22, DOC-2021-Nov21-S23, DOC-2021-Dec05-S24, DOC-2021-Dec19-S25, DOC-2021-Dec31-S26, DOC-2022-S1, DOC-2022-S2
Description
First, info on this page (https://docs.couchbase.com/nodejs-sdk/current/ref/error-codes.html) are not quite consistent with error messages of codes (https://docs.couchbase.com/nodejs-sdk/current/howtos/error-handling.html)
Should we expect couchbaseError cause 105 or cause
{kv!code0x02}or instanceof couchbase.DocumentExistsError (which seems behaviour of code)?
Second, "cluster was closed" and "parent cluster has been closed" errors that code can throw are not documented.
Attachments
Issue Links
Activity
| Field | Original Value | New Value |
|---|---|---|
| Assignee | Amarantha Kulkarni [ amarantha.kulkarni ] | Richard Smedley [ richard smedley ] |
| Labels | collector-709818cb | collector-709818cb need_info |
| Rank | Ranked higher |
| Sprint |
|
|
| Priority | Test Blocker [ 6 ] |
| Assignee | Richard Smedley [ richard smedley ] | Hakim Cassimally [ JIRAUSER25269 ] |
| Sprint |
|
|
| Sprint |
|
|
| Sprint |
|
|
| Sprint |
|
|
| Sprint |
|
|
| Sprint |
|
|
| Fix Version/s | sdk3.2-backlog [ 17245 ] |
| Epic Link | DOC-8776 [ 165484 ] |
| Sprint |
|
|
| Priority | Test Blocker [ 6 ] | Major [ 3 ] |
| Sprint |
|
|
| Sprint |
|
|
| Sprint |
|
|
| Sprint |
|
|
| Sprint |
|
|
| Sprint |
|
|
| Sprint |
|
|
| Status | Open [ 1 ] | In Progress [ 3 ] |
| Labels | collector-709818cb need_info | ImproveErrorMessages collector-709818cb need_info |
Error documented as "105" is in fact "305" in lcb, as numbers have shifted since the RFC.
As discussed with Sergey Avseyev, this enumeration isn't especially useful (it's just a backend implementation, while it's the error name that is useful in SDK land) and can be removed.
The KV error is useful and may show up elsewhere. As that was called out in ticket, will look to see if wordings can be tweaked
https://github.com/couchbase/docs-sdk-common/pull/38 for the shared part, more to come from JS sdk side.
Parent instance not closed errors seem to have been fixed as per JSCBC-896
I do get `[Error: LCB_ERR_CONNECTION_REFUSED (1024)` errors e.g. if database isn't open, that aren't an instance of CouchbaseError, so that feels like a bug, checking with sdk devs.
modules/shared/partials/error-ref.adoc:The base exception, CouchbaseException
… is called CouchbaseError in Node SDK
In general, there seems to be inconsistency between the 2 terms.
(As well as the duplicate/wrong ones below, there may be others like NodeJS that include a partial referring to the wrong base class)
❯ rg -l CouchbaseException | cut -f1 -d/ | uniq
couchbase-net-client
docs-sdk-python
docs-sdk-nodejs (WRONG)
docs-sdk-scala
couchbase-python-client
php-couchbase
spring-data-couchbase
docs-sdk-java
docs-sdk-scala
docs-sdk-common
couchbase-jvm-clients
docs-sdk-dotnet
docs-site❯ rg -l CouchbaseError | cut -f1 -d/ | uniq
couchnode
couchbase-ruby-client
docs-sdk-ruby
couchbase-rs
node-ottoman
docs-sdk-python
docs-sdk-dotnet
More shared PR https://github.com/couchbase/docs-sdk-common/pull/39
Node PR (depends on above) https://github.com/couchbase/docs-sdk-nodejs/pull/156
| Status | In Progress [ 3 ] | In Review [ 10107 ] |
| Sprint |
|
|
| Sprint |
|
|
| Sprint |
|
|
| Sprint |
|
|
| Sprint |
|
|
| Status | In Review [ 10107 ] | In Progress [ 3 ] |
closed shared PR, as that's overcomplicated.
Bulk of work was done on this ticket (see Node PR above)
| Resolution | Fixed [ 1 ] | |
| Status | In Progress [ 3 ] | Resolved [ 5 ] |
on the DocumentExistsError from Nodejs that is how the error should be propagated. I see what the user is asking, that is more of internal debugging referring to error codes but as a developer I would want to evaluate against error type or catch an exception based on error type and not number.
on the "cluster was closed" and "parent cluster has been closed" . Either its a bug that is not handled properly. Brett Lawson on the forums I see these error quite often can you please see if its due to the fact that its not handled in nodejs sdk ?