Issue Details (XML | Word | Printable)

Key: CORE-6193
Type: Improvement Improvement
Status: Open Open
Priority: Major Major
Assignee: Unassigned
Reporter: Arioch
Votes: 0
Watchers: 2
Operations

If you were logged in you would be able to see more operations.
Firebird Core

Make temporary BLOBs have non-interlapping IDs and "invalid BLOB ID" error message changed to actionable explanation

Created: 21/Nov/19 09:50 AM   Updated: 22/Nov/19 04:45 PM
Component/s: Engine
Affects Version/s: 3.0.4
Fix Version/s: None

Environment: any

QA Status: No test


 Description  « Hide
Uplifted from http://tracker.firebirdsql.org/browse/CORE-6119

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.




 All   Comments   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Karol Bieniaszewski added a comment - 21/Nov/19 06:24 PM
It does not make any sense for me. If blob ID is invalid why Firebird should look for id in different transactions?
Next you will ask if record with some value do not exist Firebird should scan all invisible record version and raport of existence somwhere else in different transaction? ;-)

Adriano dos Santos Fernandes added a comment - 21/Nov/19 06:58 PM
Also, a ID may be identical to some other temporary ID in another transaction, and it will be valid but wrong.

Arioch added a comment - 22/Nov/19 09:12 AM
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.
Firebird imposes F.U.D. upon itself.

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.

Adriano dos Santos Fernandes added a comment - 22/Nov/19 10:39 AM
"valid but wrong" does not need and has error messages, because it's not a (runtime) error.

Arioch added a comment - 22/Nov/19 11:04 AM
it is the runtime error, the infamous non-actionable zero-information "invalid blob id"

Adriano dos Santos Fernandes added a comment - 22/Nov/19 12:29 PM
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.

Arioch added a comment - 22/Nov/19 02:02 PM
> 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" ?
Maybe those errors are better indeed.
But the "invalid blob id" error is very uninformative.

> temporary id used in another transaction may be valid, but be another blob.

then tell it!

Adriano dos Santos Fernandes added a comment - 22/Nov/19 02:33 PM
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.

Arioch added a comment - 22/Nov/19 03:49 PM
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.
At least it has to be extremely rare coincidence.

> 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.
....about Firebird being easy to use correctly and hard to use wrong, or being hard to use correctly and easy to use wrong.

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.
As of now he has no such thing.
He does not know what happened except that Firebird started loosing his BLOBs.

The three distinct error messages outlines above would extract developer for which exactly problem to look in his code or in traces API

Arioch added a comment - 22/Nov/19 03:52 PM
> 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.

Adriano dos Santos Fernandes added a comment - 22/Nov/19 04:21 PM
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.

Arioch added a comment - 22/Nov/19 04:45 PM
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.
Remove line number, remove column number, remove the specific term. With absolutely the same reasoning.
SQL syntax is - quote! - well specified. Any SQL syntax error is - quote! - developer's error, which - quote! - Firebird can not fix.
Hence any extra information like the term and line and column numbers - quote! - does not improve debugging experience.

....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.