fix caching issue. and change deploy order #78

Ash1R · 2025-07-23T00:12:14Z

I think the issue was with the cache still thinking that the function is an SFX. At least thats something I was able to find.
for https://github.com/polyapi/poly-alpha/issues/4840

aarongoin · 2025-07-23T15:19:55Z

polyapi/deployables.py

-    git_revision = get_git_revision()
-    return cached_revision == git_revision

-def is_cache_up_to_date() -> bool:


Oh wow. 2 versions of the same function! 🤦 I think just deleting the second one here and keeping the first one as is would be a good change. We still want to check the cached_revision file rather than use git status --porcelain simply because there could be changes already committed into the repo which have not been picked up or prepared.

aarongoin · 2025-07-23T15:20:33Z

polyapi/deployables.py

-def write_deploy_comments(deployments: list) -> str:
-    """
-    Generate deployment comments for each deployment record.
-    """
-    canopy_path = 'polyui/collections' if 'localhost' in os.getenv('POLY_API_BASE_URL', '') else 'canopy/polyui/collections'
-    comments = []
-    for d in deployments:
-        instance_url = d['instance'].replace(':8000', ':3000') if d['instance'].endswith(':8000') else d['instance']
-        comments.append(f"# Poly deployed @ {d['deployed']} - {d['context']}.{d['name']} - {instance_url}/{canopy_path}/{d['type']}s/{d['id']} - {d['fileRevision']}")
-    return "\n".join(comments)


We can't just delete this. These comments are an important part of glide, and this function is still being called up in update_deployment_comments.

This was a duplicate function, there is still a function with this name in the file I think

Oh weird! Nice catch. 👍 Let's diff them to make sure they're the same.

They seem the same except the comment for function description

I can live with that! Delete away! 😀

aarongoin

Okay, these changes are looking good. But the Q in my mind is will we have solved the bug Eric hit where the deploy comments were put inline with import statement?

Might be worth making a new test case in polyapi-python/tests/test_deployables.py where there's imports at the very top of the file with no deploy comments and see if when we can reproduce the issue or not. test_parse_and_write_deployable_docstring would be a good one to use as a template here.

Ash1R · 2025-07-23T19:16:11Z

Added the new test, the test code string is AI generated but should replicate the scenario

aarongoin · 2025-07-23T20:05:27Z

tests/test_deployables.py

+        # ensure the first line is a deployment comment, not an import
+        first_line = updated_file_contents.split('\n')[0]
+        self.assertTrue(first_line.startswith('# Poly deployed @'), 
+                       f"Expected deployment comment at top, but first line was: {first_line}")
+
+        # Ensure imports come after the deployment comment and blank line
+        lines = updated_file_contents.split('\n')
+        import_line_index = next(i for i, line in enumerate(lines) if line.startswith('from typing import'))
+        self.assertGreater(import_line_index, 1, 
+                          "Import statements should come after deployment comments and blank line")


Everything you're testing here is already covered by self.assertEqual(updated_file_contents, expected_with_deployment_comments) right?

aarongoin · 2025-07-23T20:29:41Z

polyapi/deployables.py

+        # Add blank line after deployment comments only if file content doesn't start with blank line
+        if file_content.startswith('\n'):
+            deployable['deploymentCommentRanges'] = [(0, len(deployment_comments) + 1)]
+            file_content = f"{deployment_comments}\n{file_content}"
+        else:
+            deployable['deploymentCommentRanges'] = [(0, len(deployment_comments) + 2)]
+            file_content = f"{deployment_comments}\n\n{file_content}"


This gives me pause--not because the change or code is bad--but simply because I don't see how this could be fixing the bug Eric is encountering given this was already adding a newline in place, right?

So how did Eric get this outcome:

Looking at his picture again it seems like the deploy comment is getting formatted across multiple lines which seems odd. Nothing in here would be doing that as far as I know... Wonder if Eric has some auto-linting or formatting coming into play here. Might be worth circling back to Eric to see if he can show you his git diffs on this.

What do you think?

I agree, @eneumann is this happening consistently/is it reproducible? Also having git diffs would be helpful to see if the deployment process is changing the file.

@Ash1R yep it's consistent, here is a fresh repro on a fresh py glide project:

initial CFX

from polyapi.typedefs import PolyClientFunction polyConfig: PolyClientFunction = { "name": "cfx", "context": "foo", } def cfx(foo: str) -> str: """blah. Args: foo (str): The input string to be processed. Returns: str: A string indicating the received input. """ return f"Received foo: {foo}"

After git push:

From poly deploy action:

Preparing Poly deployments... Searching for poly deployables. Found 1 possible deployable file. Prepared server function foo.cfx: OK Poly deployments are prepared. Cached deployables and generated typedefs into polyapi/cached_deployables directory. Synced server function foo.cfx: ADDED Synced server function demo.hello_poly: NOT FOUND Poly deployments synced.

After git pull:

# Poly deployed @ 2025-07-25T00:23:22.387449 - foo.cfx - https://eu1.polyapi.io/canopy/polyui/collections/server-functions/e72cf2cd-26a7-4824-8a91-546999cb2813 - b2b9ed1from polyapi.typedefs import PolyClientFunction polyConfig: PolyClientFunction = { "name": "cfx", "context": "foo", } def cfx(foo: str) -> str: """blah. Args: foo (str): The input string to be processed. Returns: str: A string indicating the received input. """ return f"Received foo: {foo}"

@eneumann this is a long shot, but what version of the client are you using?

I dimly remember a certain recent version of the python client where EVERYTHING was deployed as a server function due to a bug in the code.

I couldn't really repro this with python -m polyapi sync and a fresh-ish env

if you are on the latest version though, i will try to repro again with a true fresh version

@eupharis I'm on v 0.3.9.dev13

Interesting. Could be an issue where the outer-most type of "client-function" is getting clobbered by the deployments type of "server-function"? Is it possible this function existed in eu1 before you deployed via glide? Like maybe it was a server function first and then we switched over, but when we deploy it doesn't change the type and it stays a server function?

@aarongoin no it was a fresh new tenant and fresh new glide project. I just pushed a new CFX and it again deployed as a SFX, but the cache has an empty deployments list.

{ "context": "fresh", "name": "freshNewCfx", "description": "blah.", "config": { "name": "freshNewCfx", "context": "fresh" }, "gitRevision": "55a7a95", "fileRevision": "e85101d", "file": "./src/clientFunctions/freshNewCfx.py", "types": { "description": "blah.", "params": [ { "name": "foo", "type": "str", "description": "The input string to be processed.", "typeSchema": null } ], "returns": { "description": "A string indicating the received input.", "type": "str", "typeSchema": null }, "raises": {} }, "typeSchemas": {}, "dependencies": [], "deployments": [], "deploymentCommentRanges": [], "docStartIndex": 178, "docEndIndex": 325, "dirty": false, "type": "client-function", "disableAi": false }

I saw a potential fix in enforcing the new type while updating in sync, but if it was new then the bug is something else?
Right now, I can't reproduce the issue, @eneumann is it still happening, and is it only an eu1 issue?

@Ash1R interestingly enough, it is only happening on EU1. Works as expected on DEV, NA2, and NA1. I used the same glide repo and thus the same CFXs and SFXx across all instances and it worked fine everywhere except EU1. I also switched to a different tenant on EU1 and it still did not work. So it can be consistently repro'd on EU1.

@eneumann fascinating! great find!

eupharis · 2025-09-22T19:51:32Z

This PR had some scary bits.

And ultimately we werent able to repro the issue.

Going to let this one go

fic caching issue. and change deploy order

45c4b4b

aarongoin reviewed Jul 23, 2025

View reviewed changes

no use of porcelain

4c917a0

aarongoin reviewed Jul 23, 2025

View reviewed changes

prevent import and deploy inline, add test

f1c55f3

aarongoin reviewed Jul 23, 2025

View reviewed changes

enforce type during sync

8009a1e

eupharis closed this Sep 22, 2025

fix caching issue. and change deploy order #78

fix caching issue. and change deploy order #78

Uh oh!

Conversation

Ash1R commented Jul 23, 2025 • edited by eupharis Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

aarongoin left a comment

Choose a reason for hiding this comment

Uh oh!

Ash1R commented Jul 23, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

aarongoin Jul 23, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Ash1R Jul 29, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

eupharis commented Sep 22, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

Ash1R commented Jul 23, 2025 •

edited by eupharis

Loading

Ash1R commented Jul 23, 2025 •

edited

Loading

aarongoin Jul 23, 2025 •

edited

Loading

Ash1R Jul 29, 2025 •

edited

Loading