FWD » Core Development » Database

Alexandru Lungu wrote:

• Extra: please check in OE what happens if buffers are loaded with something else before a CURRENT. Will the CURRENT honor whatever is already loaded or reload the queries with the last entries found?

I have observed that for a scrolling query. GET-CURRENT will load previously found records by the query. For non-scrolling case the CURRENT will honor the already loaded records.

Fix GET CURRENT to work even if that component didn't find anything. It is possible to have a record loaded using loadByValues, but the results and cursor still be empty (and the query off-end). Maybe calling the CURRENT from CompoundQuery should by-pass such checks. The CURRENT solely relies on buffer contents, so it is irrelevant if the query is off-end.

Do you have an example/testcase that shows this? At the moment I don't understand how this case should look like such that GET CURRENT would not work.

Do you have an example/testcase that shows this? At the moment I don't understand how this case should look like such that GET CURRENT would not work.

I get provide some pseudo-code:

• Run a compound query with no optimized components EACH/EACH. The results found should be (1, 2), (1, 3), (2, 3) (so a x < y condition should do the trick).
• Go through all rows with next till off-end (including off-end).
• The first AQ is at record 3; the second AQ has no records
• Run get first. This will call loadByValues and run load on both queries with (1) and (2).
  • Thus, the first AQ is re-positioned to row 1. Second AQ is not re-positioned .... its buffer is simply loaded with 2.
• Run get current. First AQ will reload row 1. Second AQ will reload the buffer; however, a call to getRow from CompoundQuery will end up in AQ.getRow that checks whether it has any results. It doesn't ... so this fails.

I fixed this in #10000 by not calling getRow for scrolling queries (that are prone to loadByValues), but rather take input from buffers directly to bypass the checking whether the query has results. It doesn't ... but it was loaded with loadByValues previously.

I made a testcase: See testcaseSee testcase

DEFINE VARIABLE resMsg AS CHARACTER.
DEFINE TEMP-TABLE tt1
    FIELD f1 AS INTEGER
    INDEX p_idx AS PRIMARY f1.

DEFINE TEMP-TABLE tt2
    FIELD f1 AS INTEGER
    INDEX p_idx AS PRIMARY f1.

DEFINE QUERY qh FOR tt1, tt2.
DEFINE QUERY qh_scroll FOR tt1, tt2 SCROLLING.

PROCEDURE initTest:
    CREATE tt1.
    ASSIGN tt1.f1 = 1.
    CREATE tt1.
    ASSIGN tt1.f1 = 2.
    CREATE tt1.
    ASSIGN tt1.f1 = 3.
    CREATE tt2.
    ASSIGN tt2.f1 = 1.
    CREATE tt2.
    ASSIGN tt2.f1 = 2.
    CREATE tt2.
    ASSIGN tt2.f1 = 3.
    OPEN QUERY qh FOR EACH tt1, EACH tt2 WHERE tt1.f1 < tt2.f1.
    OPEN QUERY qh_scroll FOR EACH tt1, EACH tt2 WHERE tt1.f1 < tt2.f1.
END PROCEDURE.

PROCEDURE logResult:
    DEFINE OUTPUT PARAMETER logMsg AS CHARACTER.
    logMsg = "(" + (IF AVAILABLE tt1 THEN STRING(tt1.f1) ELSE "?") + "," + (IF AVAILABLE tt2 THEN STRING(tt2.f1) ELSE "?") + ")".
    MESSAGE logMsg.
END PROCEDURE.

PROCEDURE testQuery:
    DEFINE INPUT PARAMETER qHandle AS HANDLE.
    DEFINE INPUT PARAMETER isScroll AS LOGICAL.

    DO WHILE NOT qHandle:QUERY-OFF-END:
        qHandle:GET-NEXT().
        RUN logResult(OUTPUT resMsg).
    END.
    qHandle:GET-FIRST().
    RUN logResult(OUTPUT resMsg).
    qHandle:GET-CURRENT().
    RUN logResult(OUTPUT resMsg).
    FIND LAST tt1.
    FIND LAST tt2.
    RUN logResult(OUTPUT resMsg).
    qHandle:GET-CURRENT().
    RUN logResult(OUTPUT resMsg).

    qHandle:QUERY-CLOSE().
END PROCEDURE.

OUTPUT TO queryResults.txt.
RUN initTest.
RUN testQuery(QUERY qh:HANDLE, NO).
MESSAGE "======Scrolling======".
RUN testQuery(QUERY qh_scroll:HANDLE, YES).

(1,2)
(1,3)
(2,3)
(?,?)
(1,2)
(1,2)
(3,3)
(3,3)
======Scrolling======
(1,2)
(1,3)
(2,3)
(?,?)
(1,2)
(1,2)
(3,3)
Warning: A buffer in query qh_scroll contains a different record than the current query result list entry. (4108)
Warning: A buffer in query qh_scroll contains a different record than the current query result list entry. (4108)
(1,2)

(1,2)
(1,3)
(2,3)
(?,?)
(1,2)
(1,2)
(3,3)
(3,3)
======Scrolling======
(1,2)
(1,3)
(2,3)
(?,?)
(1,2)
No query record is available. (4114)
(1,2)
(3,3)
(3,3)

I made some more experiments related with Scrolling/Non-Scrolling Queries.
For this testcase: Scrolling & Non-Scrolling Query testcaseScrolling & Non-Scrolling Query testcase

define temp-table ttForQuery 
    field indexPosition as integer.

create ttForQuery.
assign ttForQuery.indexPosition = 1.
release ttForQuery.

output to testCurrent.txt.

define query testQueryScroll for ttForQuery scrolling.
message "----- Scrolling: -----".
query testQueryScroll:query-prepare("for each ttForQuery").
query testQueryScroll:query-open().

query testQueryScroll:get-current().
message ttForQuery.indexPosition.

query testQueryScroll:get-first().
message ttForQuery.indexPosition.

find first ttForQuery.
assign ttForQuery.indexPosition = 2.

query testQueryScroll:get-current().
message ttForQuery.indexPosition.

find first ttForQuery.
assign ttForQuery.indexPosition = 1.
release ttForQuery.

query testQueryScroll:get-current().
message ttForQuery.indexPosition.

define query testQuery for ttForQuery.
message "----- Non Scrolling: -----".
query testQuery:query-prepare("for each ttForQuery").
query testQuery:query-open().

query testQuery:get-current().
message ttForQuery.indexPosition.

query testQuery:get-first().
message ttForQuery.indexPosition.

find first ttForQuery.
assign ttForQuery.indexPosition = 2.

query testQuery:get-current().
message ttForQuery.indexPosition.

find first ttForQuery.
assign ttForQuery.indexPosition = 1.
release ttForQuery.

query testQuery:get-current().
message ttForQuery.indexPosition.
output close. 

----- Non Scrolling: -----
No query record is available. (4114)
** No ttForQuery record is available. (91)

1
2
No query record is available. (4114)
** No ttForQuery record is available. (91)

----- Scrolling: -----
No query record is available. (4114)
** No ttForQuery record is available. (91)

1
2
Warning: A buffer in query testQueryScroll contains a different record than the current query result list entry. (4108)
1

----- Non Scrolling: -----
** No ttForQuery record is available. (91)
?
1
2
** No ttForQuery record is available. (91)
?
----- Scrolling: -----
** No ttForQuery record is available. (91)
?
1
2
** No ttForQuery record is available. (91)
?

AI Review:

• PreselectQuery.isBetweenRows is not overridden. The new "scrolling query between rows reports 4114" rule only works for FOR EACH queries. PRESELECT, presort and dynamic PRESELECT queries skip it. For example, REPOSITION q TO ROW 3 followed by GET CURRENT q on a PRESELECT query silently re-reads the old row-1 record and returns TRUE. The fix is to override it as isScrolling() && betweenRows && !_isOffEnd(). The isScrolling() guard is needed because betweenRows starts out true.

Indeed, this comes from the default interface impl.

• QueryWrapper.getCurrent: the new entry reload runs outside the try/catch that turns errors into FALSE. A lock conflict such as GET-CURRENT on a stale entry now raises ERROR instead of returning FALSE.
• QueryWrapper.beforeCurrent: when it reloads a stale entry it skips the refetch, so CURRENT-CHANGED stays FALSE even if another session updated the record.
• QueryWrapper.beforeCurrent javadoc does not match what the code does. GET-CURRENT returning TRUE together with 4114 when the query isn't off-end is correct. Only the text needs fixing.
• AbstractQuery.staleBuffers javadoc says only buffers holding a different record are counted, but empty buffers are counted too. The code looks intentional, so this is a documentation fix.
• Two blank lines were removed before return statements: in AdaptiveQuery.first and in CompoundQuery.processComponent.

Thanks for the review. Answers below; I'm working on the agreed fixes now.

• cacheFirst outside else: the behaviour is unchanged. The if branch returns next(lockType), so the code after it only runs on the former else path.
• noQueryRecord: agreed. I will rename it to failNoQueryRecord() and make it return false, so callers can return failNoQueryRecord();.
• {@code true} instead of <code>: agreed, for the new and changed javadoc.
• Guards in reloadResultListEntry: !isScrolling() and _isOffEnd() are legal states. beforeCurrent calls it for every delegate: a non-scrolling FOR EACH honours its buffers, and off-end is reported by the delegate (scrolling) or keeps the buffers (non-scrolling). In AdaptiveQuery, cursor.isBetweenRows() is already handled by beforeCurrent before the call. cursor null and entry null are defensive checks for states not expected on a scrolling query positioned on a row, so I will log them as WARNING.
• super.reposition(row, internal): this fixes a recursion. For a non-scrolling AQ, super.reposition(row) resolved to P2JQuery.reposition(int), which calls this.reposition(row, false) and lands back in AdaptiveQuery.reposition(int, boolean). That path is reachable after FORWARD-ONLY = FALSE and ends in a StackOverflowError. The fix also passes internal instead of dropping it.
• History entries: I will compress them.
• Non-scrolling query staying off-end: there are tests for an EACH/EACH compound query. After running off-end, a further GET NEXT returns FALSE, stays off-end with empty buffers, and a GET PREV then returns the last row. After running off the front, a further GET PREV stays off-end and a GET NEXT returns the first row. The OE baseline for this covers only a single-table query. The INDEXED-REPOSITION case does not apply, since a non-scrolling query cannot reposition (3164). I will add multi-table EACH/EACH, EACH/FIRST and "FIND between off-end and NEXT" cases and check in OE whether the second NEXT should touch the buffers at all.
• staleBuffers: agreed. The -1 vs 0 split comes from an OE-verified case: a scrolling OUTER-JOIN query is on an entry with no inner record, a FIND loads a record into the inner buffer, and GET CURRENT clears that buffer again without 4108. I will split it into matchesEntry(..) and staleBuffers(..) (0 = none stale).
• lockType: verified. An explicit lock overrides every component (PreselectQuery.coreFetch, RandomAccessQuery.load, and CompoundQuery.loadQuery passes it through). With null, each component uses its own lock, the same as the delegate's current().
• FQLPreprocessor: agreed, it is not in scope. It is an existing trunk bug found while running the query and persistence tests. Should I move this into another task ?
• Default reloadResultListEntry / isBetweenRows: agreed. I will make them abstract and implement them in PreselectQuery (covers AQ and presort), CompoundQuery (covers presort compound), RandomAccessQuery and QueryWrapper (including its null query). The missing PreselectQuery.isBetweenRows below is exactly this gap.
• CURRENT_* enum, and renaming beforeCurrent to getDispositionForCurrent: agreed.
• forwardOnlyAssigned: it is needed. In OE, a static query defined without SCROLLING reports 3164 on REPOSITION, but the same query repositions fine once FORWARD-ONLY = FALSE is assigned. Both states have forwardOnly == false. The alternative is a tri-state Boolean, if you prefer it.
• currentRecords: it performs the GET-CURRENT rather than checking whether it can, so I propose getCurrentRecords instead of canGetCurrentRecords.
• empty: it means "no buffer holds a record"; the loop stops at the first available buffer. That is the opposite of allBuffersLoaded. I will invert it into anyAvailable using isAvailable(). An OUTER-JOIN buffer in unknownMode has no record, so it counts as not available, matching 4GL AVAILABLE. The remaining OUTER-JOIN cases go to #11576.

• PreselectQuery.isBetweenRows: valid. I will override it as isScrolling() && betweenRows && !_isOffEnd() and add a test for REPOSITION followed by GET CURRENT on PRESELECT and presorted queries.
• Lock conflict in GET-CURRENT(): valid. The entry reload runs in QueryWrapper, outside the delegate's try/catch that turns errors into FALSE. I will apply the same error handling to the reload. I will also test GET-CURRENT(EXCLUSIVE-LOCK, NO-WAIT) when another session locks the entry's record and the buffer holds another record; so far only the GET CURRENT statement was checked in OE.
• CURRENT-CHANGED: valid for a join where only some buffers are stale. The buffers that already held their entry record are reloaded without the CURRENT-CHANGED arming, and the refetch is then skipped. I will arm/update around the reload and check in OE what the stale buffer itself should report.
• beforeCurrent and staleBuffers javadoc: valid; documentation fix only. Counting empty buffers is intended: in OE, GET CURRENT on a scrolling join after both buffers were released gives 4108 twice.
• The two removed blank lines will be restored.

• [MAJOR] functional RandomAccessQuery.current: The method now calls buffer.reloadCurrent(lockType, isErrorIfNull()), which turns a NO-WAIT lock conflict into a NO-LOCK read with LOCKED set and no error. FindQuery overrides current() / current(LockType) only to call initializeQuery() and then super.current(...), and database_access.rules maps FIND CURRENT to current, or to silentCurrent under NO-ERROR. Trigger: FIND CURRENT customer EXCLUSIVE-LOCK NO-WAIT [NO-ERROR] while another session holds the record. Before, RecordBuffer.load caught LockUnavailableException and called recordOrThrowError, so ERROR was raised (or ERROR-STATUS:ERROR was set under NO-ERROR). Now lockForCurrent swallows the exception and the statement completes silently with a NO-LOCK copy; outside a transaction any SHARE lock already held is given up. The dynamic BUFFER:FIND-CURRENT() still goes through BufferImpl._current → recBuf.reload, so static and dynamic FIND CURRENT now behave differently. This also contradicts the reloadCurrent javadoc ("Unlike FIND CURRENT ..."). Restrict the NO-LOCK fallback to the query GET CURRENT path, for example by having FindQuery.current keep the old armCurrentChanged / reload / updateCurrentChanged sequence.\

• [MINOR] functional CompoundQuery.reloadResultListEntry: When lockType == null (plain GET CURRENT q / GET-CURRENT()), lockTypes stays null, so loadEntryForCurrent never runs a component's own NO-WAIT lock through lockForCurrent. The component load falls back to its own lock type, and RandomAccessQuery.loadByValue sends the LockUnavailableException to recordOrThrowError. CompoundQuery.loadQuery rethrows the resulting ConditionException, and loadEntryForCurrent does not catch it. Trigger: scrolling OPEN QUERY q FOR EACH a EXCLUSIVE-LOCK NO-WAIT, EACH b outside a transaction, GET NEXT, a FIND on a that makes the buffer stale, another session locking the entry's a record, then GET CURRENT q. ERROR is raised (with NO-ERROR the buffer is left empty and LOCKED is not set). PreselectQuery.reloadEntry and RecordBuffer.reloadCurrent read the record NO-LOCK and set LOCKED in the same situation. Build lockTypes from each component query's lock type when lockType is null.

These 2 are related to locking.
I think this is the one you described in your last note, right? Is this a regression caused by 10026a or is it also in trunk?

• [MAJOR] functional CompoundQuery.next: The new !iterating && OffEnd.BACK.equals(getOffEnd()) short-circuit reads component 0's off-end state, which nothing on the open/close path resets. CompoundQuery.open resets only its own fields, and the components' cleanup() leaves off-end alone (RecordBuffer.offEnd for RandomAccessQuery, the offEnd field for AdaptiveQuery / PreselectQuery). Components are reset lazily in processComponent, which runs after the short-circuit. Trigger: a non-scrolling multi-table dynamic query with a non-optimized join (QUERY-PREPARE("FOR EACH a, EACH b WHERE ...")) that is run off-end with GET-NEXT and then reopened with QUERY-OPEN(). QueryWrapper.queryOpen calls close() / open() on the same delegate and components. The first GET-NEXT() then returns FALSE and releases the outer buffer instead of restarting at the first row. previous has the same problem with OffEnd.FRONT. Also require that a retrieval happened since the open (e.g. counters != null / activeIndex >= 0), or reset the component off-end state in open().

This seems reasonable.

• [MINOR] functional QueryWrapper.getCurrentRecords: getDispositionForCurrent (via reloadResultListEntry and loadEntryForCurrent) now runs before delegate.getCurrent, outside AbstractQuery.wrapCurrent's try/catch, which maps ErrorConditionException to FALSE for the GET-CURRENT method. The same applies to getCurrent() and its overloads. Trigger: q:GET-CURRENT() on a scrolling CompoundQuery defined with EXCLUSIVE-LOCK NO-WAIT, with a stale buffer and the entry record locked by another session (the path in the previous finding). The same happens with q:GET-CURRENT(EXCLUSIVE-LOCK) when a -lkwtmo lock timeout fires in loadByValue. ERROR escapes the method instead of FALSE being returned. Apply the wrapCurrent handling around the disposition step in the method variants: rethrow DeferredLegacyErrorException and map ErrorConditionException to FALSE.
• [MINOR] functional QueryWrapper.getDispositionForCurrent: Each stale-buffer 4108 goes through its own ErrorManager.recordOrShowWarning call inside the loop. Under CATCH or BLOCK-/ROUTINE-LEVEL ON ERROR UNDO, THROW, recordOrShowError upgrades the warning and throws DeferredLegacyErrorException on the first iteration, so the error carries only one 4108. OE 12.8 raises one error carrying every 4108. Trigger: two-table SCROLLING query, GET FIRST, FIND LAST on both tables, then GET CURRENT inside a CATCH; OE gives NumMessages = 2 and FWD gives 1.

I think these are optional. It may be subject to the lack of proper structured error handling in FWD. If it is a quick fix, please do it, otherwise ignore it. Also, the first point is about locking.

Conclusion: if the locking limitation is also in trunk and not a regression feel free to defer it for now.

Stefanel, are #11992 changes required in trunk to also have #10026? In other words, are they inter-dependent or simply additive one to the other?

Alexandru Lungu wrote:

Stefanel, are #11992 changes required in trunk to also have #10026? In other words, are they inter-dependent or simply additive one to the other?

They are independent.

I have only:

• MAJOR: CompoundQuery.reloadResultListEntry: GET CURRENT q with no lock phrase can reload the wrong record. This happens on a scrolling client-side join opened with EXCLUSIVE-LOCK NO-WAIT, when another session locks the entry record and the buffer holds a different record. The lock conflict is swallowed, the old record is re-read and locked, and LOCKED is not set. PreselectQuery.reloadEntry already handles this case correctly. The fix is to derive the lock types from the components, as it does.
• MINOR: RecordBuffer.reloadCurrent: outside a transaction, a failed EXCLUSIVE-LOCK NO-WAIT upgrade drops the SHARE lock the session already holds. lockForCurrent returns NONE, which relinquishes that lock. It should fall back to the pinned lock type.

I will start testing on my side. Let me know if you have the chance to look into these 2 items.
At the end, I will do a final manual review.

Alexandru Lungu wrote:

• MAJOR: CompoundQuery.reloadResultListEntry: GET CURRENT q with no lock phrase can reload the wrong record. This happens on a scrolling client-side join opened with EXCLUSIVE-LOCK NO-WAIT, when another session locks the entry record and the buffer holds a different record. The lock conflict is swallowed, the old record is re-read and locked, and LOCKED is not set. PreselectQuery.reloadEntry already handles this case correctly. The fix is to derive the lock types from the components, as it does.
• MINOR: RecordBuffer.reloadCurrent: outside a transaction, a failed EXCLUSIVE-LOCK NO-WAIT upgrade drops the SHARE lock the session already holds. lockForCurrent returns NONE, which relinquishes that lock. It should fall back to the pinned lock type.

I have a few findings related to these two, that seem to work wrong in trunk too, I'm waiting for the test results and then report.
In the end, I'll send an email to request this branch to be tested for more projects.

I checked both review findings with two-session probes on OpenEdge, trunk (r16809) and this branch: session A runs the GET while session B holds a lock, then B reports which locks A holds.

Summary: neither finding can happen in valid 4GL, so neither proposed fix is needed. Each one points to a real gap, and every gap below already exists in trunk. The branch's conversion change for NO-WAIT on the lock methods is correct.

Finding 1: CompoundQuery.reloadResultListEntry¶

OpenEdge rejects NO-WAIT in any query record phrase (OPEN QUERY, FOR EACH, DO PRESELECT, QUERY-PREPARE) with error 247, so a query component never has a NO-WAIT lock. The closest valid code is GET CURRENT q NO-WAIT (no lock type), and both FWD versions get it wrong:

Cause: the conversion drops a NO-WAIT that has no lock keyword and emits plain current() (rules/convert/database_access.rules).

Finding 2: RecordBuffer.reloadCurrent¶

OpenEdge never takes EXCLUSIVE-LOCK outside a transaction. A static GET makes its block the transaction, and the GET methods fail with error 7359 ("QUERY GET methods with exclusive lock requires a transaction"). FWD has no 7359:

Inside a transaction, the branch matches OpenEdge, while trunk raises "Could not acquire exclusive lock".

Branch conversion change: NO-WAIT on GET-*/FIND-* methods¶

Trunk drops a literal NO-WAIT (or 6090) from these methods, so they wait for the lock. The branch keeps it in every form tested (literal, 6090, variables, query and buffer handles). On the branch, GET-CURRENT and every FIND-* method then match OpenEdge. GET navigation does not:

The statement shows the runtime gap is already in trunk; the branch only exposes it for the methods.

What needs to change¶

• GET methods: raise 7359 when EXCLUSIVE-LOCK is requested without an active transaction.
• GET navigation with NO-WAIT (statement and method): when another session holds the lock, read the record with NO-LOCK and set LOCKED instead of raising an error.
• GET CURRENT q NO-WAIT: keep the NO-WAIT in conversion, and apply it to each component's own lock at runtime (in CompoundQuery, derive the lock types from the components, as PreselectQuery.reloadEntry does).
• Optional: raise 247 at conversion time for NO-WAIT in an OPEN QUERY, FOR or PRESELECT record phrase.

Not checked: a zero NO-WAIT argument (both versions remove it, so the call waits).

I reaches the same conclusions as #10026 so I can confirm them they are not relevant now. Please proceed with testing.

The two customer applications that I tested are both fine with 10026a. Nothing suspicious noted. ✅

Branch regression: 10026a¶

Two tests in the lock battery pass at the fork (trunk r16766) and fail on the task branch (r16772), and both failures reproduced on a rerun. Apart from those two, the branch fixes 94 tests and regresses nothing else.

Regressions (2), both in tests/concurrency/get_current_lock¶

• TestGetCurrentLockWriter.cls#GL08StaleJoinExclNoWaitNoErrorEscapes: OE pass, baseline pass, task fail. AssertionFailedError at HarnessApi.sendMessage(HarnessApi.java:401): the writer timed out after 120 s waiting for the reader.
• TestGetCurrentLockWriter.cls#GL10StaleJoinGetCurrentNoWaitNoLockPhrase: OE pass, baseline pass, task fail. Same timeout.

What changed is the reader. At the fork, the GL08 and GL10 readers fail at once on a wrong value, and the writer finishes normally. On r16772 the reader blocks, apparently on a record lock: GL08 waits about 240 s, GL10 about 120 s and then fails its assertion. While the reader is blocked, the writer gives up waiting. So the branch turns a fast wrong answer into a hang in a NO-WAIT stale-join scenario. The battery's own notes predicted the GL10 hang on r16772, and the ticket says the branch is now at r16812; the newer revisions may have fixed this.

Conclusion¶

Considering that the 2 tests are OK on trunk, but failing with this branch, considering them regressions, we might expect seeing such exploit in customer application after merge. On the other hand, if these 2 tests were passing by chance and they are actually meant to be failing in trunk due to a lack of functionality, then I am ok porting them to a b branch. Stefanel, please investigate these 2 tests with urgent priority.

Fixed (94)¶

• get-current: 34 tests, across 18 classes. Examples: the 11882 dynamic EACH/FIRST CURRENT after OPEN, 7 tests in the error-mode surroundings, compound CURRENT right after OPEN, and presort CURRENT between rows.
• get-error-modes: 34 tests, in the CURRENT error-mode classes (empty query or join, off-end join, past end).
• query-db: 16 tests, mostly get_current_join.
• lock battery: 3 tests (GL04 and GL05 reader, GL05 writer).
• Lyra browse suite: 2 tests.
• Smaller suites: 2 in current-changed, 2 in off-end-state, 1 in reposition-past-last.

Notices¶

• More to fix: 279 tests pass on OE but fail on both builds.
  • The ones that point at the branch's own bug: 38 in get-current, 10 in the lock battery, 13 in the Lyra browse suite and 10 in get-error-modes. Many get-current ones are from the later review notes (#10026-16/-20: reopen after off-end, several stale buffers under CATCH or THROW), so r16812 may cover them.
  • In the browse suite, FWD returns join rows reversed, for example (3,2) where OE has (2,3).
  • The rest (off-end-state, reposition-past-last, query-db) look like existing gaps, unchanged by the branch.
• OE red: 105 tests fail on OE. 86 are in query-db, which was kept by choice: 56 from 10068 in reposition_to_rowid_outside_where, plus Assert:Equals overloads (14457). 13 are in progressive-results and 6 in current-changed (a table from the tstmultiple database, plus 14457).

Things that affect how to read this¶

• Version: r16772 was tested, as on disk. The branch is now at r16812.
• Lock battery: run one scenario per harness run (GL01 premise plus the scenario) on both FWD sides. A full run desynchronises after the first scenario that hangs (GL02), and every later scenario fails without running. On OE the full battery ran cleanly, 20/20.
• Lyra: the 2 real-input scenarios use the OE verdict recorded in MAPPING.md on 2026-10-22; they were not rerun on OE. The 17 class ports were rerun on OE (prowin) and all pass.
• Conversion failures: 25 files failed to convert and 13 had javac errors, the same on both sides (no rules/ change). They show up as err/not run in off-end-state and query-db.
• Probe file: Probe10026Join.cls is a scratch probe by its own header and was left out of the frozen test copy.

Comparison¶

err = runtime error, not run, conversion failure or skipped.

PS: I am committing the tests just now.

Done in rev. 1958.

I'll check these tests out. I guess it it could be related to #10026-24 findings. There are two options here: Either I revert the NO-WAIT patches I made in 10026a to how trunk handled it or I should make a complete fix for the CURRENT NO-WAIT support.

Sorry, my bad, I think I forgot to push --overwrite after I rebased the branch and applied other fixes.

Status of the two lock-battery regressions from #10026-27. That run tested r16772; 10026a is now at r16812.

I reproduced GL08 and GL10 with a pair of two-session probes, on trunk r16812 and on 10026a r16812. In every case the other session holds the outer record of the query entry with EXCLUSIVE-LOCK. I did not rerun the harness battery itself.

GL08 is fixed in r16812. In r16772, conversion dropped the NO-WAIT from GET-CURRENT(), so the reload waited. r16812 keeps it.

GL10 is not a new bug in 10026a. Conversion (in trunk as well) drops NO-WAIT when no lock keyword is given, so GET CURRENT q NO-WAIT becomes a plain current() and waits for the lock. Trunk returned at once in this case only because it did not reload the entry and kept the wrong record. When trunk does reload (last row), it waits too.

A full fix needs NO-WAIT kept in conversion and applied to each query component's lock at runtime. That touches the query API and four query classes, which is too much to change safely before the merge. I propose a follow-up task for GET CURRENT q NO-WAIT without a lock keyword. No change is needed in 10026a.

Got it; thank you for investigation. I have no other objections.
Please let me if you are ready to merge 10026a.

Alexandru Lungu wrote:

Got it; thank you for investigation. I have no other objections.
Please let me if you are ready to merge 10026a.

I finished testing on my side and also received confirmation from Serban and Artur that their tests were ok. I think 10026a is ready to be merged. Then, I guess I should create a followup task to fix the NO-WAIT support.