Triple term from BIND inside a sub-SELECT is silently dropped when the sub-SELECT is joined

[jitsedesmet]

Version

main (6.3.0-SNAPSHOT) and Fuseki 6.2.0.

What happened?

I was running some experiments and came across a potential bug in Jena. Since I have no Java knowledge, I asked claude to look at the issue and it does look legit.
I asked Claude to create a regression test. From that test I can see that indeed both tests should pass, but only the first one does. I also asked Claude to fix the issue and the code looks clean, if yoiu want, a PR can be started from that solution by the maintainers or by me, just say the word.

What follows is a description generated by Claude code:

---

When a sub-SELECT projects a variable bound by BIND(<<( ... )>> AS ?tt) and that sub-SELECT is joined against a sibling pattern, ?tt comes back unbound. The result set has the correct rows and row count — only the triple-term column is missing, with no warning or error, so a caller cannot detect it from the response.

Data:

  @prefix : <urn:> .
  :g1 :hasX "x1" .
  :g1 :hasB "b1" .

Query:

  PREFIX : <urn:>
  SELECT * WHERE {
    { SELECT ?g ?tt WHERE { ?g :hasX ?x . BIND( <<( ?x :p :o )>> AS ?tt ) } }
    ?g :hasB ?b .
  }

Got ?g and ?b bound, ?tt absent. Expected ?tt = <<( "x1" :p :o )>>. Without the join, or with a plain { } group in place of the sub-SELECT, the result is correct.

Cause

ApplyTransformVisitor.visit(ExprTripleTerm) returns the term without applying the ExprTransform, so no algebra transform reaches variables inside a triple term in an expression. Sub-SELECT scope renaming (TransformScopeRename
→ Rename.renameVars, ?x → ?/x) therefore produces inconsistent algebra:

    (extend ((?tt (tripleterm ?x <urn:p> <urn:o>)))    <- not renamed
      (bgp (triple ?g <urn:hasX> ?/x))))               <- renamed

?x is unbound at evaluation time, so the BIND raises VariableNotBoundException and extend leaves ?tt unbound. Renaming only happens when the sub-SELECT is joined with something, which matches the observed trigger condition.

Relevant output and stacktrace

Are you interested in making a pull request?

Maybe

[afs]

Thank you.

The AI analysis is useful - it is realistically short and to the point.

Checking the spec,
There is a possible second bug : <<( "x1" :p :o )>> is not legal (literal in the subject position).
CONSTRUCT, INSERT removes them, but expressions should as well but maybe should be in results handling. I'm not clear when the validation should be done. (Corner case, triple terms as intermediate values i.e. not returned in the results).

[jitsedesmet]

If I recall correctly this is part of the TRIPLE operation and should throw an expression error?

[afs]

Let's keep that as a separate issue.

#4176 addresses the report about missing conversion.