Different behavior for append (POST) and update (PUT) rows

[Garvash]

I need to add and update rows via API.
Addition works fine: getting token and base_uid, then POST
/api/v2/dtables/7c8efa4a-6baf-40ef-9114-74cd01569934/rows

After that trying to update, with PUT on SAME url and modifed json:
{“updates”: [ {“row”:{…},“row_id”:“…”}],“table_name”:“…”}

Got 500 response. And error in log
PUT /api/v2/dtables/7c8efa4a-6baf-40ef-9114-74cd01569934/rows/: failed to get base 7c8efa4a-6baf-40ef-9114-74cd01569934 from dtablecache

What ID do I need to use ?

[cdb]

Self-hosted (and version) or cloud?

[Garvash]

Self-hosted,
4.4.9 enterprise
5.0.0 dev

Just checked - update on 5.0.0 works
We plan to update Enterprise in this month, so I can wait unil then

[cdb]

So topic can be closed?

[Garvash]

Let’s wait for a one week. May be it’s not only version issues

[Garvash]

@cdb , after upgrading error still exist
Now we have:
Self-hosted,
5.0.8 enterprise - creating ok, updating produce error above
5.0.0 dev - no error for creating and updating

[cdb]

Please post the complete commands and the output here (don’t forget to replace the bearer tokens with ***).

I am quite sure this is not a bug in SeaTable. Instead, I am sure this is a configuration error and your dtable-server can not connect to mariadb or the api-ateway is configured wrong. But I will see this, as soon as you post your requests.

[Garvash]

I have a loop, with two envs (EXT - community, INT - enterprise)

So, first iterations goes through one env (EXT), second - through the next (INT)
It is the $env variable
inside iteration - same commands. And choosing between creating or updating.

At first, getting table id and access_token
$response = $this->req($this->url[$env . ‘_base’] . ‘/api/v2.1/dtable/app-access-token/’, $this->token[$env][‘hr’]);
$token[$env] = json_decode($response)->access_token;
$baseId[$env] = json_decode($response)->dtable_uuid;

It works for both envs, here is the dump for stored variables:

So, the base connections is ok.

Then, inside each iteration there is loop through the persons.
For now i am trying to:

1. create record for person in both tables - works well for both envs
2. Updating this record - works only for one env,

I am using such construction for PUT

Http::withHeaders([
‘accept’ => ‘application/json’,
‘authorization’ => 'Bearer ’ . $token
])->asJson()->put($url, $data);

where

$url = $this->url[$env] . ‘/v2/dtables/’ . $baseId[$env] . ‘/rows/’,

$data = [
‘updates’ => [[
‘row’ => $data,
‘row_id’ => $row_id
]],
‘table_name’ => ‘…’
]

Configuration of nginx (location for /api-gateway) is the same

urls looks like
https://{{}}/api-gateway/api/v2/dtables/7c8efa4a-6baf-40ef-9114-74cd01569934/rows/
https://{{}}/api-gateway/api/v2/dtables/4afa4a7b-4f85-4cf1-8c14-5c5288a2a9e7/rows/

[cdb]

What should I do with your description? I can not check your requests for any errors, because you send them only partially or just describe what you do.

Here is what I just executed:

Append row

curl --request POST \
     --url https://<our-test-system>/api-gateway/api/v2/dtables/47029039-02bd-4d30-ae4b-08fb56b83e79/rows/ \
     --header 'accept: application/json' \
     --header 'authorization: Bearer xxx' \
     --header 'content-type: application/json' \
     --data '
{
  "table_name": "Table1",
  "rows": [
    {
      "Name": "4"
    }
  ]
}
'

Result of append row

{
  "inserted_row_count": 1,
  "row_ids": [
    {
      "_id": "c3FSFf7STtin1IOVdUJqvA"
    }
  ],
  "first_row": {
    "0000": "4",
    "_creator": "",
    "_last_modifier": "",
    "_id": "c3FSFf7STtin1IOVdUJqvA",
    "_ctime": "2024-09-23T16:12:55.608+00:00",
    "_mtime": "2024-09-23T16:12:55.608+00:00"
  }
}

Update row

curl --request PUT \
     --url https://<our-test-system>/api-gateway/api/v2/dtables/47029039-02bd-4d30-ae4b-08fb56b83e79/rows/ \
     --header 'accept: application/json' \
     --header 'authorization: Bearer xxx' \
     --header 'content-type: application/json' \
     --data '
{
  "table_name": "Table1",
  "updates": [
    {
      "row": {
        "Name": "4new"
      },
      "row_id": "c3FSFf7STtin1IOVdUJqvA"
    }
  ]
}
'

result of update row

{
  "success": true
}

Summary:

There is no problem with SeaTable API.
Your error message is saying, that the base can not be read from dtablecache. Therefore, I would recommend that you check memcached, redis and mariadb first.

One idea that just came to my mind:
Probably mariadb can not write the operation_log because the disc is full or there is a problem with the database connection…

If there is no problem, then check all log files to get more details about the problem.

[Garvash]

Dear Christoph,

I understand, that it’s not a API bug. I post here to get a help with finding a root of problem. Because I already checked logs and can’t find any keys to solution…

After some research i found, that problem only with this base. And complete error leads to some issues with links. Sorry, i haven’t provided full error log:

[error] PUT /api/v2/dtables/7c8efa4a-6baf-40ef-9114-74cd01569934/rows/: failed to get base 7c8efa4a-6baf-40ef-9114-74cd01569934 from dtablecache: dtablecache.BaseValue.Links: dtablecache.Link: dtablecache.Link.T
1Map: string: ReadString: expects " or n, but found {, error found in #10 byte of …|s0j3IgQ",{“_id”:“GKl|…, bigger context …|OwxrGUDoRTujUw9N9WJPvg”,“ZtHeoj56QQi0F2ls0j3IgQ”,{“_id”:“GKlevdRUQhWWx2maVZeszg”,“_mtime”:"2024-06-1|.

Before that we created links with api. And looks like after deleting some rows links still persisted…

Here is how it’s looks in the record. But i can’t delete it from interface

[cdb]

It seems we’ve shifted focus. Initially, your post suggested an issue with the SeaTable API, but now it appears the problem lies with an individual base.

Unfortunately, troubleshooting specific base issues is outside the scope of this forum. However, I can suggest two possible approaches:

• Create a backup of your base, then systematically delete data or elements until it starts working again.
• Create a new base and gradually transfer data from the original one to identify the issue.

Best regards