Refactoring and re-submitting a bite is not submitting the refactored code

[Se7enSquared]

Not sure if I'm doing something wrong, but when I submit a bite then refactor it, go to the bite on the pybites site and choose "try again" and then submit through eatlocal again, my old non-refactored code is re-submitted.

I'm on Windows 11 using PowerShell to submit

[rhelmstedter]

I've noticed that too. There is a note on the pybites website under the offline mode tab: (Note: raw.githubusercontent.com uses a CDN so commits might be a few minutes delayed.) I don't know what a CDN is, but I wonder if that is the cause.

When you check your git repo, is the refactored code there? If so, I don't think that is an eatlocal problem.

[rhelmstedter]

I just ran into this problem right now. I submitted bite 17 through eatlocal successfully. I clicked try again. I refactored my code locally and submitted a second time through eatlocal. The pybites website (pybites from here on) had my old non-refactored. I went over to github and confirmed my refactored code was in fact committed. Back on pybites I manually tried to use the "download code" button. It was still my old non-refactored code. I tried manually a few more times and even tried refreshing pybites to no avail. While I did not time it, I finally manually submitted my code on pybites after what felt like 2-3 mins.

Since eatlocal is using selenium to simulate clicking the "download code" button, this leads me to believe it is not an eatlocal problem, rather a lag between pybites and github. @bbelderbos do you have any thoughts on this?

Some possible (though not ideal) work arounds:

1. Refactor code after passing tests but before submitting through eatlocal.
2. Wait a few mins before resubmitting after clicking "try again" and refactoring.

This did spark a couple of ideas:

• I wonder if I could get eatlocal to check if the refactored bite was downloaded on pybites and if not hold off on submitting. (I could see that being annoying though...)
• Would it be helpful to have a eatlocal tryagain command that would reopen the bite from the command line?

[bbelderbos]

Thanks @rhelmstedter and @Se7enSquared for flagging this.

I would need to reproduce this to better understand the issue.

A quick look at the code and we create the URL to pull from like this:

GH_CODE = 'https://raw.githubusercontent.com/{user}/{repo}/{branch}/{biteid}/{script}'
# later the pieces get interpolated using `.format()`

I think we only use a single branch right? I don't see a commit hash in this url so would it just take the latest commit by default, right? (Sorry, it has been a while we implemented this feature.)

CDN is a content delivery network and I found in our code a comment linking to this SO answer: https://superuser.com/a/1322590 - so a delay of 5 minutes is to be expected. Is the issue going beyond this time interval?

Cheers, Bob

[rhelmstedter]

I haven't timed it but I haven't noticed it past five mins.

[bbelderbos]

Let's look at this together when we have our eatlocal meeting :)

[rhelmstedter]

With v2, I believe this is no longer an issue. playwright replaces whatever is in the editor and submits.