Moving http validations during initialisation (as proposed)

[afsalthaj]

! warning ! - I don't think this is correct (I raised a PR - for the purpose of discussion and clarity)

Trying to fix #2935

This is just a new PR instead of #2967, addressing the review comment of #2967 (comment).

@vigoo If I understood this comment correctly, then its not ideal behaviour. After trying this PR change myself as a user, I can confirm this is definitely not what I want :)

For example, with this PR (http mount/endpoint validation error during initialisation), below given is calling an agent method using REPL, where the agent was configured with wrong http configurations just to bump into late errors.

This should ideally be a build/deploy error during golem deploy (i.e., on the main branch).

In my view, the correct place to run HTTP validations is at decorator execution time—not elsewhere. That’s because HTTP mounts and endpoints are configurations defined at the @agent decorator level. Any misconfiguration there should surface as a decorator-level error (i.e., a JS import failure).

A similar case is unsupported types. If we define an agent using unsupported types, it shouldn’t be treated as a deployment or agent-initialization error. The system simply cannot import it—so there’s no discovery or initialization possible.

As a side note, I re-evaluated the validations currently present in the SDK. Some of them are duplicated in the backend (so even if skipped in the SDK, deployment would still catch them), but not all. The SDK includes additional checks—for example, validating whether a user is binding an HTTP path variable to a Principal. Because of such cases, these validations cannot be removed. Just noting this for context.

[vigoo]

Part of the build is extracting the agent metadata - it's always executed if the code changed, and it can return (typed) errors. We used this for reporting errors that are determined "runtime" but always reported build-time because we always build with golem-cli that handles this correctly.

[vigoo]

So the solution is not to do it in initialize! It has to be returned by the discover-agent-types.

[afsalthaj]

So the solution is not to do it in initialize! It has to be returned by the discover-agent-types.

Yes, that's the next immediate thought I had too. Whenever we call discover-agent-types, iterate through all agents, and re-validate the http details.. Again we store the "invalid agent-types (an invalid agent-type is wrong mount details)" in the registry first. Yet.... I am thinking this:

AgentType has http details (mount and endpoint in each AgentMethod) in it. There might be situations (if not today, tomorrow) where some time we cannot even form an AgentType because of an invalid mount or endpoint details (or similar situations in other domains), resulting in not able to store this agent-type in the registry unless we store errors too in registry (hmm).

Again, all of these are easy to do, but don't feel right.

[vigoo]

You don't need to store invalid agent types in the registry. You just record the failure in a global state and when the extractor calls the function, you return with an error, and not with the list of agent types. This is our clean way to communicate "code-first validation errors", because if you panic / throw an exception, that's just a single trap instruction in wasm, and we have to reverse engineer the stdout/err for getting the details.