Local Service Chaining blocks spin start

[seungjin]

> spin --version
spin 3.3.0-pre0 (66fee279 2025-04-01)

> spin plugins list --installed
check-for-update 0.1.0 [installed]
cloud 0.11.0 [installed]
platform 0.1.0 [installed]
pluginify 0.7.0 [installed]
test 0.1 [installed]
trigger-command 0.2.2 [installed]
trigger-cron 0.1 [installed]

Getting this error at spin startup and can't start spin up.

Error: failed to parse app lock file JSON

Caused by:
    invalid version 1 != 0 at line 2 column 24
Logging component stdio to ".spin/logs/"

Serving http://127.0.0.1:3000
Available Routes:
  root: http://127.0.0.1:3000
  assets: http://127.0.0.1:3000/static (wildcard)
A trigger exited unexpectedly. Terminating.

only when I add this into my spin.toml

[component.foo]
source = "wasm/foo.wasm"
allowed_outbound_hosts = ["http://random-place.spin.internal"]

Other normal urls are fine, just Spin's Local Service Chaining url emits error and block spin start.

[rajatjindal]

I tried this in one of my app by just modifying the spin.toml and adding allowed_outbound_hosts = ["http://random-place.spin.internal"], but it starts just fine for me.

spin --version
spin 3.3.0-pre0 (747c9fe 2025-04-02)

from spin.toml

[component.hello]
source = "main.wasm"
allowed_outbound_hosts = ["http://random-place.spin.internal"]

spin up       
Logging component stdio to ".spin/logs/"

Serving http://127.0.0.1:3000
Available Routes:
  hello: http://127.0.0.1:3000/hello

[rajatjindal]

do you happen to have this app published somewhere I can try from?

[seungjin]

Ok. I will get a generalized example of this issue.
My app is a mix of HTTP and cron triggers in a microservice architecture.
Mixing them probably caused this issue.
I will provide a more generalized case later tonight.

[seungjin]

You can check this tree: https://github.com/seungjin/foo.fermyon.app/tree/9559ed0324db9073c0a4f39afa45397abfd18f95

Seems this happens only when I mix http and cron triggers.
https://github.com/seungjin/foo.fermyon.app/blob/9559ed0324db9073c0a4f39afa45397abfd18f95/spin.toml

[itowlson]

[component.cron-me]
source = "wasm/cron_me.wasm"
allowed_outbound_hosts = ["http://internal-service.spin.internal"]

At the moment, unfortunately, you can only service chain from HTTP components to HTTP components.

Both of these work only from HTTP components. That is, if you want to make an intra-application request from, say, a Redis trigger, you must use a full URL.

https://spinframework.dev/v3/http-outbound#making-http-requests-within-an-application

We should for sure do a better job of reporting the limitation - Spin should at least stop with a clear error message. I'll look into this.

[seungjin]

What about this: https://github.com/seungjin/foo.fermyon.app/blob/4f0b262d8b96283df91b7763d96ee352a77262aa/spin.toml#L31
I set Local service chaining between http triggers but the same error.
Seems whatever I do, once there is a cron trigger, spin is not running up with local service chaining.

[itowlson]

That does sound like a bug - thanks for clarifying! I will take a look.

[itowlson]

I have a suspicion this has a similar cause to #2915. Both multi-trigger and app splitting involve subsetting the components, and the "must support service chaining" host requirement is naively propagated to each subset, whereas it should be recalculated for each subset.

(ETA: Actually I think this is the same issue as #2915. I thought there was another one for subsetting but #2915 implies that it was already fixed for subsetting. In which case I might not be able to back some stuff out!)

(ETAYM: It was not already fixed for subsetting.)

[itowlson]

Hmm, maybe multi-trigger is not subsetting - maybe the subsetting is done within the trigger command (and all triggers receive the same lockfile). That would have been easier to implement for sure, but makes the fix more difficult. I'm wondering if, now we have subsetting, we can refit multi-trigger to use the same logic, then fix the subsetting logic just once. Not sure how painful that will be but I will keep digging.

[itowlson]

Okay I have a candidate fix, and it looks to fix #2915 as well. It's a bit revolting and results in multiple passes and multiple parsings which seems a bit, well, unparsimonious. But now I know it seems to work I can tidy it up and see if there are any opportunities to make it repeat work less (and give it fuller testing). Unlikely to be ready to PR today but hopefully tomorrow!