We already have a WorkerServiceRibInterpreter service in the worker-service module, which handles the details of the worker-gateway (worker-service). To maintain consistency, this PR introduces WorkerServiceRibCompiler, responsible for compiling Rib Expr in a way specific to the worker-gateway. Example: WorkerServiceRibCompiler ensures that the only allowed global variable in the Rib scrip is a request.
Removed the pure_evaluate function in the worker-service module. It was slightly harder to reason about, as it primarily dealt with evaluating Rib expressions without function calls (e.g., resolving a worker-name expression). This has been replaced with directly calling the rib::interpret_pure function. This is useful anytime we need to evaluate a Rib expression anywhere in Golem.
The function-type registry is a map of RegistryKey to RegistryValue. RegistryKey is a FunctionName, but it included includes Enum, Variant, etc. As I was improving Rib, I find this part confusing, so I cleaned it up. To begin with, I wanted to treat everything as a generic function call and delegate the responsibility of differenting whether it is a Variant/Enum or actual worker-function call to the Rib Interpreter. However, that turned out to be a long-term goal with many brittle logic points. So it is still almost the same except that RegistryValue will hold the information whether or not it is a Variant. This allows safer pattern match and logical decisions during type inference. This adjustment allows for more context-aware error messages. Example: Instead of "wrong number of arguments to register-user," we can have "wrong number of arguments to variantregister-user". Likewise, we have the flexibility to add more information in the error messages.
Renaming of some important variables, adding an fixing comments making it easier to understand the workflow of serving a custom http request for a new developer.
Early error messages for invalid function calls before going to other phases of compilation which makes the error message more opaque due to extra details.
Incorrect number of arguments for function `foo`. Expected 1, but provided 2
Incorrect number of arguments for resource constructor `cart`. Expected 1, but provided 2
Invalid type for the argument in resource method `golem:it/api.{cart(user_id).add-item}`.
Expected type `record`, but provided argument `\"foo\"` is a `str`
Fixes #966, #797, and other cleanups:
We already have a
WorkerServiceRibInterpreter
service in the worker-service module, which handles the details of the worker-gateway (worker-service). To maintain consistency, this PR introducesWorkerServiceRibCompiler
, responsible for compiling RibExpr
in a way specific to the worker-gateway. Example:WorkerServiceRibCompiler
ensures that the only allowed global variable in the Rib scrip is a request.Removed the
pure_evaluate
function in the worker-service module. It was slightly harder to reason about, as it primarily dealt with evaluating Rib expressions without function calls (e.g., resolving a worker-name expression). This has been replaced with directly calling therib::interpret_pure
function. This is useful anytime we need to evaluate a Rib expression anywhere in Golem.The function-type registry is a map of
RegistryKey
toRegistryValue
. RegistryKey is aFunctionName
, but it included includesEnum
,Variant
, etc. As I was improvingRib
, I find this part confusing, so I cleaned it up. To begin with, I wanted to treat everything as a generic function call and delegate the responsibility of differenting whether it is a Variant/Enum or actual worker-function call to theRib Interpreter
. However, that turned out to be a long-term goal with many brittle logic points. So it is still almost the same except thatRegistryValue
will hold the information whether or not it is aVariant
. This allows safer pattern match and logical decisions during type inference. This adjustment allows for more context-aware error messages. Example: Instead of "wrong number of arguments to register-user," we can have "wrong number of arguments tovariant
register-user
". Likewise, we have the flexibility to add more information in the error messages.Renaming of some important variables, adding an fixing comments making it easier to understand the workflow of serving a custom
http
request for a new developer.Early error messages for invalid function calls before going to other phases of compilation which makes the error message more opaque due to extra details.
etc