Replit behaving very strangely, code that worked 1 minute ago doesn't work now?

Trying to run my Replit, over the past few hours have been having these problems where even regular print statements don’t work (right before/after a print statement that does!).

It’s also like it’s not being saved, but it says it is.

Weirdly, I’m not getting any error either, just 500.

If I try to remove a print statement, it just continues to print.

I tried logging out and back in, which worked for ~5 minutes, then back to buggy stuff.

I don’t know what is happening in the slightest.

Would be happy to hear any advice.

please send the repl link

2 Likes

Do you think it could be a problem with the code? How could it be not even printing, then? Are there connectivity issues going on?

1 Like

I literally do not know and would need the repl link (the repl link provides more info then just code)

1 Like

Ok, it’s private right now currently, do I unprivate it and send you the link?

1 Like

I mean, if it’s got private info, don’t unprivate it, or you can just like explain the lang, some code snippets where you think it’s wrong, what you’ve tried thus far, etc

3 Likes

If there are API keys or something like that, they should be put in secrets, regardless of whether it’s private.

3 Likes

Ok that’s the problem, it does. It’s Python, running the replit SQL db. Like I said, literal print statements will work one minute and not the next. Or I’ll delete an entire line, and the repl will behave as if the line is still there… It’s as odd as it sounds.

1 Like

If I invite people to the replit, can people see what’s in secrets?

2 Likes

Yes. Anyone invited to a Repl can see its secrets. They have all the privileges you do except Repl name, publish settings, etc.

2 Likes

hmm, very strange latency bugs, I will try notifying a dev @ShaneAtReplit

1 Like

Also, if someone who was invited to a Repl forks it, their fork will contain any secrets from the previous one (it’s some kind of new thing Replit’s testing).

1 Like

Thank you, I get this briefly in the console before my code boots, I’m not sure what it is or if it is in any way relevant, and I still struggle to see how this could account for phantom print statements and so on:
Screen Shot 2023-06-19 at 3.29.18 PM

Have you invited anyone else to the Repl or run any commands in shell? I know it is possible to create a read-only filesystem in a Repl as I’ve seen @9pfs1 do this.

2 Likes

That’s not from chmod -R u-w $HOME/$REPL_SLUG (that’d be Permission denied), I think that’d probably be if the physical (or maybe virtual) disk device that the repl’s files are stored on had an issue, causing the filesystem that their repl is stored on to be remounted in read-only mode.
Here’s what happens if you try to make the files in a Repl read-only:

~/9pfs$ cd /tmp/
/tmp$ mktemp -d
/tmp/tmp.7P1wwQviXk
/tmp$ cd tmp.7P1wwQviXk/
/tmp/tmp.7P1wwQviXk$ ls
/tmp/tmp.7P1wwQviXk$ mkdir -p whee/a;chmod -R u-w whee/;rmdir whee/a
rmdir: failed to remove 'whee/a': Permission denied
/tmp/tmp.7P1wwQviXk$ 

To compare, here’s what they’re probably having issues with:

/tmp/tmp.7P1wwQviXk$ cd /etc/
/etc$ mkdir wtf
mkdir: cannot create directory ‘wtf’: Read-only file system
/etc$ 

@Cortif44 Could you run mount|grep /home/runner/$REPL_SLUG in your repl while it’s misbehaving like that and send the output?

1 Like

So I ran it in the shell and I got:

/dev/nbd13 on /home/runner/PersonalMultiserverdiscBot type btrfs (ro,noatime,ssd,flushoncommit,space_cache=v2,commit=60,subvolid=257)

Uh… wtf? Why’s your repl’s filesystem read-only? :eyes:

Could you run kill 1 and see if it’s still read-only after that?

1 Like

I ran kill 1 in the shell, and now I get:

/dev/nbd36 on /home/runner/PersonalMultiserverdiscBot type btrfs (rw,noatime,ssd,flushoncommit,space_cache=v2,commit=60,subvolid=257,subvol=/working_subv)

2 Likes

Does it work correctly now?

It appears to be working correctly, but it sort of goes in and out of working. I’ll mess around for a bit and get back to you.

1 Like