Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fbaetens/bump sqlite kv limit & improve error reporting #2724

Merged
merged 4 commits into from
Sep 18, 2024

Conversation

Frederik-Baetens
Copy link
Contributor

No description provided.

@Frederik-Baetens
Copy link
Contributor Author

This also has an internal PR

kj::Array<byte> buffer = serializeV8Value(js, field.value);
ActorStorageLimits::checkMaxValueSize(field.name, buffer);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, by doing this means that if we get a giant value we're going to keep it around until the check kicks in later. I guess this is probably safe, if only because if the value were too huge, the isolate would have run out of memory before we got here.

src/workerd/api/actor-state.c++ Outdated Show resolved Hide resolved
src/workerd/io/actor-cache.c++ Outdated Show resolved Hide resolved
src/workerd/util/sqlite-kv.h Outdated Show resolved Hide resolved
// of KJ exceptions which become internal errors.
class SqliteKvRegulator: public SqliteDatabase::Regulator {
void onError(kj::StringPtr message) const override {
JSG_ASSERT(false, Error, message);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This implementation will throw JSG errors for all possible SQLite errors. Almost everything about this class is under our control so every error EXCEPT the TOOBIG error should be an internal error. Is it possible to report only TOOBIG errors this way?

Copy link
Contributor Author

@Frederik-Baetens Frederik-Baetens Sep 17, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, but not without either doing matching on the string message (bad), or changing the onError API (out of scope for now).

What I'll do now is only pass the regulator to the put query, so only sql errors for put get passed through. Or would you prefer I do string matching as a temporary kludge here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changed it to only report errors on the put query. Let me know your thoughts on that. I acknowledge it's a bit of a hack, but I think its a low consequence change here. Reporting an SQLite error that's actually our fault to the user doesn't seem like a massive issue for sqlite here.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, including the error code in the onError doesn't seem that difficult actually. I'll try to get something out based on that.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pushed a fixup commit passing the error code to onError. Let me know what you think of that, and I'll squash it if you think it's a good approach here.

@Frederik-Baetens Frederik-Baetens force-pushed the fbaetens/bump_sqlite_kv_limit branch 2 times, most recently from 9ef86fa to 46c544d Compare September 18, 2024 08:59
@Frederik-Baetens Frederik-Baetens force-pushed the fbaetens/bump_sqlite_kv_limit branch 2 times, most recently from ab70a64 to 3453abb Compare September 18, 2024 10:46
@@ -3,6 +3,7 @@
// https://opensource.org/licenses/Apache-2.0

#include "pyodide.h"

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This got in from running the formatter.

@@ -15,8 +17,22 @@ namespace {
// In this case we just customize the error reporting to emit JSG user visible errors instead
// of KJ exceptions which become internal errors.
class SqliteKvRegulator: public SqliteDatabase::Regulator {
void onError(kj::StringPtr message) const override {
JSG_ASSERT(false, Error, message);
void onError(kj::Maybe<int> sqliteErrorCode, kj::StringPtr message) const override {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like this approach of taking in the error code. However, it would be better if you put the definition of onError in the C++ file. Doing so means that we wouldn't need to #include <sqlite3.h> in this header file, which means that other headers won't have to include sqlite3.h, which means @sqlite3 can remain an implementation_dep, which means builds should not slow down.

Copy link
Contributor Author

@Frederik-Baetens Frederik-Baetens Sep 18, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done this now, I had put it in the header file to be able to put it in an anonymous namespace, but I suppose that doesn't matter much.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FYI for future reference, don't put anonymous namespaces in headers. This causes everything that includes the header to compile its own copy of the stuff in the anonymous namespace. This bloats the binary and could lead to ODR violations.

src/workerd/util/sqlite-kv.h Outdated Show resolved Hide resolved
Copy link
Contributor

@justin-mp justin-mp left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the code itself is in good shape, but we're missing a test in sqlite-kv-test.c++.

Or is there a reason that we shouldn't include a test?

@Frederik-Baetens
Copy link
Contributor Author

I tested this in the internal PR, but I'll add a test there too then.

@Frederik-Baetens Frederik-Baetens merged commit 183b548 into main Sep 18, 2024
12 of 13 checks passed
@Frederik-Baetens Frederik-Baetens deleted the fbaetens/bump_sqlite_kv_limit branch September 18, 2024 21:42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants