imbajin opened a new pull request, #3317:
URL: https://github.com/apache/hugegraph/pull/3317

   An OLTP edge consumer could stop with its prepared iterator still open when 
a callback failed, requested early stop or was interrupted. With more than one 
serializer batch, the underlying RocksDB cursor could still own its native 
handle even after caller transaction cleanup.
   
   Close the owned iterator in `finally`: use the prepared iterator after 
successful preparation, and the original input if preparation fails. Reuse the 
existing close helper so a closing failure is suppressed on the original 
exception. Caller transactions and traversal counters keep their existing 
behavior.
   
   Validation: isolated real RocksDB regressions observe the native iterator 
after caller cleanup while a separate control lease keeps the database alive. 
They fail before the fix and pass afterward, covering callback failure, stop, 
interruption, preparation failure and closing failure. Focused Maven RocksDB 
tests, Java 17 formatting, clean reactor compilation and three independent 
reviews passed.
   
   Related release issue: SV10, a separate cursor-ownership defect from [worker 
transaction binding #3314](https://github.com/apache/hugegraph/pull/3314). This 
covers consumed inner iterators; complete C04, queued iterators and distributed 
acceptance remain separate. No public API, configuration or dependency changes 
(`Doc - No Need`).
   
   Source org PR: [#295](https://github.com/hugegraph/hugegraph/pull/295). This 
uses the same source branch and commit after the current-head org checks passed.
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to