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
Make temporary BLOBs have non-interlapping IDs and "invalid BLOB ID" error message changed to actionable explanation [CORE6193] #6438
Comments
Commented by: @livius2 It does not make any sense for me. If blob ID is invalid why Firebird should look for id in different transactions? |
Commented by: @asfernandes Also, a ID may be identical to some other temporary ID in another transaction, and it will be valid but wrong. |
Commented by: Arioch (arioch) It is exactly this situation "valid but wrong" that leads to ambiguous thus non-actionable error messages. "id is invalid" - why did it become invalid? what to do to make it valid again? why Firebird is making valid IDs invalid? Is it safe to rely on a database that has a habit of making valid BLOBs invalid when you need them? That is what every novice feels now. And even those users who got used to see such errors - they have to ask FB Core Team to run their custom EXE and debug Firebird server sources to explain what happened. |
Commented by: @asfernandes "valid but wrong" does not need and has error messages, because it's not a (runtime) error. |
Commented by: Arioch (arioch) it is the runtime error, the infamous non-actionable zero-information "invalid blob id" |
Commented by: @asfernandes You didn't understand! The error is not given all times an id is used wrongly. In many cases an temporary id used in another transaction may be valid, but be another blob. |
Commented by: Arioch (arioch) > The error is not given all times an id is used wrongly. huh? so what are the cases you mean, when "id is used wrongly", but "different error is given" ? > temporary id used in another transaction may be valid, but be another blob. then tell it! |
Commented by: @asfernandes If you get temp-id=1 in transaction x and open blob with id=1 in transaction y, trasaction y may have created another temporary blob with id=1, so you will open wrong blob and there is no runtime error. You seem to understand that as subj. says "Make temporary BLOBs have non-interlapping IDs and invalid BLOB ID", but for sure the thing is about development error, and have the transaction id in the message does not make debug necessary easy. The problem seems you want to give the debug power to the operator, but will only be able to send the message to the developers with will have do debug the same thing anyway. |
Commented by: Arioch (arioch) And so we made a full circle, almost, at last. > so you will open wrong blob and there is no runtime error. So there should be an error, a clear and descriptive error, and no opening wrong blob should be possible. > for sure the thing is about development error ....and about Firebird either promoting correct use of it with easily fixable errors, or promoting wrong uses of it with arcane non-informative errors. As of now, this part of Firebird API is the latter. > but will only be able to send the message to the developers No. One thing is to debug "s**t happens" and quite another is to debug a narrowly defined situation with much more clearly described factors. > with will have do debug the same thing anyway. No, he will finally have "the thing" to debug. The three distinct error messages outlines above would extract developer for which exactly problem to look in his code or in traces API |
Commented by: Arioch (arioch) > have the transaction id in the message I did not say a word about adding transaction ID into error message, actually I thought I heard it is already there in recent versions. But anyway, no I did NOT say about tx Id in the error message and do not have an idea why you talk about it. |
Commented by: @asfernandes My opinion is to close that ticket as there is nothing to fix or improve. Firebird could not fix developers mistakes and error is already informative and behavior of blob ids is well specified. The suggested changes does not improve the debugging experience. |
Commented by: Arioch (arioch) It does enhance debugging by clearly documenting which of the three very distinct problems happened. Continuing this logic you have to remove all "extra" information from SQL syntax errors. ....except that developer can read SQL query text, every letter of it, and is in much better starting position, than with "invalid BLOB id" error, where developers typically has no information about API calls and Firebird volatile IDs/handles except the guesswork. |
Submitted by: Arioch (arioch)
Uplifted from CORE6119
As of now the infamous "Invalid BLOB id" error means "s..t happened, hope you're lucky to guess which specific one".
Reliable reproduction of bugs is not always possible.
And even in lucky cases when it is, it is not always possible to dispatch a developer with full sources and full development environment to the customer site.
Even in double-lucky case when it was possible, it is straining to narrow down the case to simple demo exe and then demand someone from FB core team to debug Firebird server w.r.t. that demo project.
So it would be nice if Firebird reported three different typical cases w.r.t. temporary blobs:
- this blob is real but is not accessible from this transaction, isolation violation between transactions A and B
- this blob likely did existed but does no more, too late
- this blob id is total lunacy, makes no any sense
Such an error, reported immediately by firebird to application, application to user and user to vendor, will give much more information to app developers than "s..t happened, you did not learn some of your lessons" reported now.
What prevents distinguishing and reporting different errors by engine is overlapping of blob ids - "blob_id 1 at txA is not the same as temporary blob with blob_id 1 at txB"
Making them non-overlapping would provide for better instant diagnostics and for moving this class of errors from "Those are just things that routinely happen with Firebird" into "clear cause is known and what code to fix in application can be easily found" domain.
For two easy examples of de-overlapping, a temporary blob_id can be taken form in-memory GENERATOR, or can be constructed as transaction id hash in high digits with linear per-transaction counter in lower digits, counter overflows would be quite OK in these cases, so no limits upon continuous uptime of database connections would be imposed. Extra burden on the server, accounting for all other works for BLOB transfers, should not be significant either.
The text was updated successfully, but these errors were encountered: