Description
Describe the bug
All attempts at an http scry into the gall scry namespace fails. While this is not yet officially supported, I spent some time tracking down why it doesn’t work currently in 410K and wanted to share. I’ll give an example for reproducing it and then explain how an untyped cage is causing the problem in the additional context.
To Reproduce
Steps to reproduce the behaviour:
- in a gall agent pass:
[%pass /wire/man %grow /cool/bro [%mime [/text/plain (as-octs:mimes:html 'surfs up!')]]] - http scry into gall: let’s assume the agent is running in the
%basedesk.
http://localhost/_~_/===/gx//1/cool/bro - in the browser you should see:
'scry failed'
Expected behaviour
The text 'surfs up!' displayed in the browser.
System (please supply the following information, if relevant):
- Vere 3.4 and Urbit OS 410k
Additional context
Essentially gall places an untyped cage ($page) into the scry namespace and eyre attempts to convert from the given mark into a mime type. But the raw, untyped noun causes a crash in two different places.
Given the desk has the appropriate /mar files, the http scry will fail on line 3555 =/ res (mule |.((tube vase))). Mule will discover that the given vase is untyped and return a nest-fail.
If a %mime marked noun is grown into the gall scry namespace, like the example above, it will fail on line 3525 [%& !<(mime p.mym)]. Extracting the untyped vase to mime crashes.
I don’t know the proper way to resolve this. I assume gall is behaving properly because a scry in our dojo is successful (mime .^(* %gx /===//1/cool/bro)). And a %keen note passed in another ship’s agent will succeed too.
Notify maintainers
@midden-fabler @Fang-