@kensio/yulin 1.21.28 → 1.21.30

package/docs/services/athena/README.md

@@ -383,8 +383,8 @@ test's own statement about a query the engine gets wrong.
 
 ### Failing a statement Athena refuses
 
-One failure ignores strict mode. Where the engine can see that Athena would refuse a statement
-outright, the query fails whether strict mode is on or off. A turn-down means the engine reached its
+Two failures ignore strict mode. This section covers the first. Where the engine can see that
+Athena would refuse a statement outright, the query fails whether strict mode is on or off. A turn-down means the engine reached its
 limits, and a declaration is a fair answer to that. A rejection means the SQL is invalid, and
 answering from a declaration would leave a test green on a query that fails against AWS.
 
@@ -411,6 +411,18 @@ well, since the two names differ and nothing shadows.
 Trino and SQLite resolve names by different rules in other places too, and the engine catches this
 one. A statement that behaves differently under the two is worth reporting.
 
+### Failing a value a function cannot read
+
+The second failure that ignores strict mode comes from a Trino function the engine runs. Where one
+cannot answer faithfully for a value the statement hands it, the query fails with a
+`StateChangeReason` naming the function and the value. `date_add('fortnight', ...)` fails this way,
+and so does `CAST(sku AS DATE)` over a column holding no date.
+
+The engine took the statement on and ran it, so falling back would answer from rows a declaration
+wrote for some other purpose. A query with no declaration of its own would answer from the
+default, which is often no rows at all, and a test reading it would see an empty result with no
+error. A declaration written against the exact query text still answers it.
+
 ### The objects it reads
 
 The SerDe class name in the table's storage descriptor says how its objects are decoded.
@@ -560,7 +572,7 @@ call written inside a string literal is left alone as well.
 instant it froze, and the same test answers the same way on every machine. Athena reads both at the
 instant the query started, which is what the execution records.
 
-A function that cannot answer faithfully raises rather than guessing, and the query falls back.
+A function that cannot answer faithfully raises rather than guessing, and the query fails.
 `date_add` with a unit Trino does not name, `slice` starting at zero, `array_join` over an array of
 objects, `least` over a `varbinary`, and `regexp_extract` naming a capture group the pattern has not
 got all land there. A null
@@ -1064,7 +1076,7 @@ Current documented limitations:
   statement comparing the answer against a bare string matches on one and not the other.
 - A timestamp carrying a numeric UTC offset falls outside the date functions, and so does one
   written finer than the millisecond. A value written with a `Z` or with no zone at all reads as
-  UTC, and a value the date functions cannot read turns the query down.
+  UTC, and a value the date functions cannot read fails the query.
 - A JSON number beyond about fifteen significant digits loses the digits past that, wherever the
   engine reads JSON. An identifier of that size in a JSON lines object comes back rounded, and a
   filter on it can then match the wrong row.
@@ -1088,9 +1100,9 @@ Current documented limitations:
   written any other way gets whatever slicing that text comes to.
 - A `varbinary` in a result row reads as its bytes decoded as UTF-8. A digest read that way loses
   whatever in it was no UTF-8. A query answering with one wants `to_hex` or `to_base64` around it.
-- `from_hex` and `from_base64` turn the query down over text the encoding cannot carry. Trino fails
-  the query, and reading as much of the text as parses would answer with bytes nobody wrote.
-- `from_utf8` with a replacement named turns the query down where the bytes already carry the
+- `from_hex` and `from_base64` fail the query over text the encoding cannot carry, as Trino does.
+  The alternative, reading as much of the text as parses, would answer with bytes nobody wrote.
+- `from_utf8` with a replacement named fails the query where the bytes already carry the
   replacement character. Trino writes the replacement only where a sequence was broken, and nothing
   survives decoding to tell one of those apart from a character the bytes held.
 - `spooky_hash_v2_32` and `spooky_hash_v2_64` are absent, and so are the other Trino hashes with no
@@ -1107,7 +1119,16 @@ Current documented limitations:
   runs.
 - `try_cast` runs as a plain cast. `try_cast('abc' AS integer)` therefore answers 0 where real
   Athena answers null, which is the same forgiving direction as the cast above. Reading the
-  statement without the rewrite would turn the whole query down.
+  statement without the rewrite would turn the whole query down. A `try_cast` to `DATE` or
+  `TIMESTAMP` over text the cast cannot read fails the query, where Athena answers null.
+- `CAST(x AS DATE)`, `date(x)` and `CAST(x AS TIMESTAMP)` read text the way Trino's cast from
+  `varchar` does. A date is `yyyy-MM-dd` and nothing else. A timestamp is a date, optionally
+  followed by a space and a time, with no `T` and no zone. A timestamp renders as
+  `2026-08-15 10:00:00.000`, and a fraction finer than the millisecond is rounded.
+- A cast reads its value as text only where it is a string literal or a column the catalog declares
+  as `string`, `varchar` or `char`. Anything else, such as a `timestamp` column or the answer of a
+  function, is taken to be a date or a timestamp already, and any ISO-8601 form of it is accepted.
+  The answer is text in a `varchar` column, where Athena reports a `date` or a `timestamp`.
 - A `decimal` column is held as a double. A value carrying more than about fifteen significant
   digits loses the ones past that, and a filter, a sum or a group on it can then answer
   differently from Athena's exact arithmetic.

package/docs/services/lambda/README.md

@@ -152,6 +152,9 @@ The vm runtime models the real Node.js runtime closely:
   (`AWS_REGION`, `AWS_LAMBDA_FUNCTION_NAME`, `AWS_LAMBDA_FUNCTION_MEMORY_SIZE`, ...).
 - The sandbox provides writable `process.stdout` and `process.stderr`, with its `console` built
   over them, as the real runtime does. See [What a handler prints](#what-a-handler-prints).
+- The sandbox provides the other globals of the Node.js runtime, including `global`, the WHATWG
+  streams, `EventTarget`, `atob`, `performance` and `navigator`. `Date` and the timers follow the
+  simulated clock. `performance.now()` reads host time.
 - Import and handler problems surface as invocation errors, with the real runtime error types
   (`Runtime.ImportModuleError`, `Runtime.HandlerNotFound`, `Runtime.UserCodeSyntaxError`,
   `Runtime.MalformedHandlerName`). Creation succeeds either way.
@@ -728,8 +731,8 @@ Some deployment packages inline the SDK rather than relying on the runtime to pr
 `NodejsFunction` does that when given `bundling: { externalModules: [] }`. There is then no
 `@aws-sdk/*` module left for the runtime to provide, and nothing to intercept.
 
-Those functions reach the simulation anyway. The runtime provides their HTTP transport, `node:http`
-and `node:https`, and a request addressed to an AWS API endpoint is answered from the same
+Those functions reach the simulation anyway. The runtime provides their HTTP transport, `node:http`,
+`node:https` and `node:http2`, and a request addressed to an AWS API endpoint is answered from the same
 simulated services, as the same execution role, instead of going to the network. The execution
 role credentials are in the function's environment, as real Lambda puts them there. The SDK resolves
 credentials inside the sandbox, where it would otherwise fail with `CredentialsProviderError`.
@@ -746,6 +749,13 @@ sends. A function can read and write Objects with an `S3Client` its archive inli
 Role authorizes each request, and a read it holds no `s3:GetObject` for comes back to the SDK as
 `AccessDenied`.
 
+Bedrock Runtime states its operation and its model in the path, and its client sends over HTTP/2.
+`Converse`, `ConverseStream`, `InvokeModel` and `InvokeModelWithResponseStream` from a bundled
+`BedrockRuntimeClient` return what `simAws.bedrock().responses()` declares, and the SDK reads the
+two streaming operations as it reads a real event stream. A model id given as an inference profile
+ARN works too. The execution Role authorizes each call, and a denial reaches the handler as
+`AccessDeniedException`.
+
 A bundled call to any other simulated service, such as SNS, SES or Lambda itself, fails with an
 error naming the service. Leaving the SDK out of that archive puts it back
 on the module interception path above, which every simulated service is reachable through.
@@ -761,8 +771,8 @@ hostname, along with everything else a handler asks for over HTTP.
 ## The HTTP requests function code makes
 
 A request from a handler to a hostname the simulation serves is answered by the simulation. It
-never leaves the process. `fetch`, `node:http` and `node:https` all reach it, so it makes no
-difference which client the handler was written with.
+never leaves the process. `fetch`, `node:http`, `node:https` and `node:http2` all reach it, so it
+makes no difference which client the handler was written with.
 
 Two kinds of hostname are served. Everything simulated Route53 resolves is answered over the same
 in-process HTTP entry point a browser on localhost reaches. That covers a
@@ -4358,9 +4368,9 @@ Sim Lambda currently supports:
 - Per-function environment variables with `Environment.Variables`
 - Runtime-provided `@aws-sdk/*` packages inside function code, routed into the owning simulated AWS
   environment
-- `fetch`, `node:http` and `node:https` requests from function code, answered by the simulation for
-  every hostname it serves, including a Cognito user pool domain's OAuth endpoints and the JWKS a
-  token verifier fetches from the regional Cognito endpoint
+- `fetch`, `node:http`, `node:https` and `node:http2` requests from function code, answered by the
+  simulation for every hostname it serves, including a Cognito user pool domain's OAuth endpoints
+  and the JWKS a token verifier fetches from the regional Cognito endpoint
 - Execution roles, evaluated against simulated IAM
 - Published versions and aliases, with `PublishVersion`, `ListVersionsByFunction`, `CreateAlias`,
   `UpdateAlias`, `GetAlias`, `ListAliases` and `DeleteAlias`, and a `Qualifier` on `Invoke`,
@@ -4470,7 +4480,7 @@ Current documented limitations:
 - Environment variables declared with `Environment.Variables` reach a real in-process handler
   function only while it runs, so a variable read at module scope sees the host process value
   instead. See [Environment variables](#environment-variables).
-- Outbound HTTP is routed for `fetch`, `node:http` and `node:https` alone. A handler using another
+- Outbound HTTP is routed for `fetch`, `node:http`, `node:https` and `node:http2` alone. A handler using another
   client, or a request made from a handler module while it is being imported, reaches the network.
   A routed response comes back as the simulation answered it, with redirects left for the caller to
   follow. See [The HTTP requests function code makes](#the-http-requests-function-code-makes).

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@kensio/yulin",
-  "version": "1.21.28",
+  "version": "1.21.30",
   "description": "AWS system behaviour simulation for isolated unit testing",
   "repository": "https://github.com/KensioSoftware/yulin",
   "homepage": "https://yulinsim.dev/",