Skip to content

prevent generation crash in mixed TS/Python environments and harden s…#101

Open
palimad wants to merge 4 commits intodevelopfrom
4230-mixed-ts-python-returntype
Open

prevent generation crash in mixed TS/Python environments and harden s…#101
palimad wants to merge 4 commits intodevelopfrom
4230-mixed-ts-python-returntype

Conversation

@palimad
Copy link
Copy Markdown

@palimad palimad commented Mar 18, 2026

https://github.com/polyapi/poly-alpha/issues/4230

This PR fixes a deploy-time crash in mixed TypeScript/Python environments where generated Python annotations could reference a non-existent ReturnType module attribute. The server function renderer now avoids unsafe namespacing for the special ReturnType case, preventing AttributeError during generate flows. It also hardens generation paths against non-string metadata shapes by normalizing schema title/root values and description inputs before string operations. These changes improve resilience of codegen against inconsistent spec payloads. Regression test coverage was updated around the ReturnType issue.

@palimad palimad requested a review from eneumann March 18, 2026 12:50
Pavol Madeja added 2 commits March 18, 2026 13:52
Copy link
Copy Markdown
Member

@eneumann eneumann left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for working on this one @palimad!

One concern: this special-case returns bare ReturnType. Can you confirm ReturnType is actually bound in generated __init__.py globals at import time?

Current test asserts -> dict, so it doesn’t exercise the bare ReturnType path. If that name is unresolved, deploy/import can still fail.


def _normalize_return_type_for_annotation(function_name: str, return_type_name: str) -> str:
if return_type_name == "ReturnType":
return "ReturnType"
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does bare ReturnType resolve at import time in generated __init__.py?

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great catch, thanks. I updated the fix so utility types are normalized before Python annotation generation, which removes the bare ReturnType import-time dependency. So generated imports in init should not be part of the resolution path anymore.

@palimad
Copy link
Copy Markdown
Author

palimad commented Apr 2, 2026

@eneumann I fixed the mixed TS/Python deploy crash by adding a shared normalization step before Python codegen works with return types. This now converts TS utility-style types like ReturnType, typeof, Promise, Awaited, and TS unions into safe Python-friendly types early in the flow.
Because of that, utility tokens no longer leak through as Python symbols.
The change is wired into common type resolution/import qualification logic, so it works consistently instead of patching one edge case. It works for me now, could you please check if it fixes also your issues?

Copy link
Copy Markdown
Member

@eneumann eneumann left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@palimad thanks for fixing the return type issue!
Looks like just one more little fix needed for type mismatch between normalizer and server wrappers.


if type_spec["kind"] == "plain":
value = type_spec.get("value", "")
value = normalize_cross_language_type(type_spec.get("value", ""))
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This now normalizes \Promise<string | null> to str | None, but server wrappers still only use resp.text for exact str and otherwise call resp.json().

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants