Variables passed in Expression.apply sometimes not resolved in imported jslts

[orElse]

For maintainability I have some commons and utils extracted to separate files which can be reused in my actual transformation jslts - for tracking the context of data I am also adding some variables during the apply which I than add to the transformed data via the defs inside the commons/utils.

Additionally I have a small string map resolver for the additional files since I cannot put them inside the classpath resources.

I have the issue that the injected variables are not available in all imported files - at the moment I am just not sure if it is a general issue or due my resolver (wouldn't hope that) - I tried to reduce the code to bare minimum reproducer (sorry that it is in scala)

With the import order in the test I am getting a:
com.schibsted.spt.data.jslt.JsltException: No such variable 'test-request-id' at commons.jslt:4:19
if I switch the imports it is fine, since my actual jslts are more complex I can currently not solve this with import reordering ( I probably have to merge all my additional/common jslts to one file as a workaround for now)

class JsltPropertiesSpec extends AnyWordSpec
  with must.Matchers
  with TryValues
  with EitherValues {

  import java.util.{Collections => JCollections}

  private val mapper = new ObjectMapper()

  val contextVariables: util.Map[String, JsonNode] = {
    import scala.jdk.CollectionConverters._
    Map(
      "test-request-id" -> new TextNode("1234").asInstanceOf[JsonNode]
    ).asJava
  }

  case class StringMapResolver(commonJsltPatterns: Map[String, String]) extends ResourceResolver {
    override def resolve(importedJslt: String): Reader = {
      commonJsltPatterns.get(importedJslt) match {
        case Some(pattern) => new StringReader(pattern)
        case None => throw new JsltException(s"""Could not resolve imported JSLT pattern "$importedJslt"""")
      }
    }
  }

  def toExpression(transformPattern: String, commonPatterns: Map[String, String] = Map.empty): Expression = {
    new Parser(new StringReader(transformPattern))
      .withSource("<inline>")
      .withFunctions(JCollections.emptySet())
      .withResourceResolver(StringMapResolver(commonPatterns))
      .withObjectFilter(". != null or . != {}") // empty arrays are omitted by default
      .compile()
  }

  def transformJson(expression: Expression, rawJson: String, context: util.Map[String, JsonNode] = contextVariables): Try[String] = Try {
    val input: JsonNode = mapper.readTree(rawJson)
    val mapped = expression.apply(context, input)
    mapped.toString
  }


  "JsltProperties" should {
    val jsonString =
      """
        |{
        |  "name": "test"
        |}
        |""".stripMargin

    "be resolvable in 'let' inside 'def' loaded via import" in {
      val commons = Map(
        "utils.jslt" ->
          """
            |def required(fieldValue, errorMessageFieldName)
            |  if ($fieldValue)
            |    $fieldValue
            |  else
            |    error("JobId: "+ $test-request-id +" missing required field: " + $errorMessageFieldName)
            |
            |""".stripMargin,
        "commons.jslt" ->
          """
            |
            |def get-request-id-commons()
            |  let requestId = $test-request-id
            |  $requestId
            |""".stripMargin
      )

      val expression = toExpression(
        """
          |import "commons.jslt" as commons
          |import "utils.jslt" as utils
          |
          |def get-request-id()
          |  commons:get-request-id-commons()
          |
          |{
          |  "name" : utils:required(.name, "name"),
          |  "request" : {
          |    "id" : get-request-id()
          |  }
          |}
          |""".stripMargin,
        commons
      )

      val result = transformJson(expression, jsonString)
      result.success.value mustEqual """{"name":"test","request":{"id":"1234"}}"""
    }
  }
}

[larsga]

It sounds like this is a bug. A variable defined in one module shouldn't be visible in another module at all. So I think you need to rewrite this so that you don't have these cross-module variable dependencies.

I'll fix the bug, but the fix is going to be making sure this never works. :-)