Fix Unknown Item Type Specification

[garrettmflynn]

fix #652

This happened because there is no explicit item type for this property, and the default method was deriving the type from the first item—which didn't exist and therefore was undefined.

If no initial value exists to check, we are now assuming the array is an array of strings.

[CodyCBakerPhD]

I remember this issue now

It actually stems from our method signature inference on annotation typing in NeuroConv not supported nested values like list[str]

When we implement the Pydantic method over there this should all be taken care of and we can do a big update of all such options

Though we could technically define it now by hard-coding it into the get_source_schema for that interface

we are now assuming the array is an array of strings.

That might be incorrect, though. Could you instead have the modal print a message along the lines of 'unknown schema type for interface option' or else detect it ahead of time and not display the modal?

[garrettmflynn]

I'll define a hook that lets you specify custom behavior for when the input type has not been recognized from the schema (which is currently to print out the default value or, if nonexistent, indicate that there is no default value).

In this case, you'd rather have the property omitted than guess the structure of an improper JSON Schema?

[CodyCBakerPhD]

In this case, you'd rather have the property omitted than guess the structure of an improper JSON Schema?

Yeah. It could just as easily be a list of integers, or list of floats, etc. for any given interface

Plus the real trick of some of these (which pydantic will not completely solve for us either) is that their true proper schema isn't known until we read a little but of the file (i.e., need to know the source path first then determine the rest)

[garrettmflynn]

Ah sure. How's this?

[CodyCBakerPhD]

Looks fine, broader question is if we want to display this kind of stuff or hide it away from the user. It might be a little while until this gets entirely fixed

[garrettmflynn]

That's fair. I can define a way to hide these errored properties in production, but show the above message in Development.

Would this be too complicated to keep track of? Or d'you think this could be a good long-term solution?

[bendichter]

catalystneuro/neuroconv#774

[bendichter]

I don't really want to print errors for failed rendering of optional arguments. This is really non-essential for conversion and we should not concern a user with its failure to render, but it would be helpful to know this internally so we can keep it on our to do list. I like the idea of displaying this in dev but not in prod, I think that addresses this nicely.

[CodyCBakerPhD]

Fine with me as well

[garrettmflynn]

This is hidden in production now!

[CodyCBakerPhD]

Looks like this breaks the main argument of the Audio interface

@garrettmflynn Can you push a fix to the schema for the Audio interface? Fine to override get_source_schema with hardcoded translation of a 'list of strings' for now

[CodyCBakerPhD]

Also what environment does the storybook use to generate snapshots? It seems like it's not using the proper version of NeuroConv for the Phy rendering

[garrettmflynn]

Storybook uses the generated schema from generateInterfaceSchema.py, so we'll need to run that to update any of the schema aspects.