[FIXED] [HELP!] Database Issues, Glitch shows data after refresh but FS doesn't?


#1

When I use fs.readFileSync on a json file, it sees only part of each object. It shows the exact object, just without the last 2 fields. Glitch shows these fine inside of the file, but readFileSync doesn’t.

I have a json table:

[
    {
        GameKey: "",
        Username: "",
        Password: "",
        Cookie: "",
        BotID: ""
    }
]

Glitch shows that in my file when I refresh my project, but FS sees this:

[
    {
        GameKey: "",
        Username: "",
        Password: ""
    }
]

My project name is roblox-ranking-service.


MOD EDIT: formatting


#2

Hey @efewqefwfd what are you doing with the JSON data once you’ve read it in from the file - how are you getting to the content that you posted in your message?

What you posted as the example of the JSON file you’re trying to process isn’t valid JSON. If you’re parsing\ it in order to get at the content you posted is it possible the parsing is failing?

Also where is the JSON coming from? I looked in your project for some test data that I could play with, but none of the JSON files I found had exactly the format you posted.


#3

I have something that adds the last 2 lines to each one, I copied the json to the post and copied it wrong, so I have fixed it. I do .forEach on it and console.log the object to get the one with only 3 lines instead of 5. Glitch shows it perfectly fine in the JSON file and no errors occur, but the readFileSync doesn’t see it after using writeFile to save the 2 added lines.


#4

Can you post snippets of the code that’s operating on it, or point us to the appropriate lines in your files?


#5

They start on Line 368 and 620


#6

Did you find any issues or a solution?


#7

So I’ve looked this over a few times and I don’t see anything suspect in the fs calls themselves. I also examined accounts.json and I do not see that any but the last record has been updated with the new values you’re adding - is that what you’re expecting?

I’m not 100% sure precisely what you’re trying to accomplish, but here’s what I think you’re trying to accomposh, so correct me if I’ve got something wrong here:

  1. something POSTs to /c and you do some work and update the in-memory accounts list and try to write it back to accounts.json
  2. something else POSTs to /rankingPortalV1 and reads accounts.json, and you’re expecting to have the account information updated in (1) be present there.

If I’ve got that correct then the only thing I can think of is that you have a race condition between POST /c and POST /rankingPortalV1 so that the /rankingPortalV1 call is happening before the write in /c is completed. Using writeFileSync in /c won’t prevent a new request to /rankingPortalV1 from beating it to the file. You could check this by putting console.log(Date.now()) in each method along with some identifying information to compare when calls are coming in or being completed.


#8

I’m 100% it calls read file sync after writing as I manually send the requests to my server for testing.


#9

So you call /c, wait and manually verify that the file’s been updated, then call /rankingPortalV1 and fs reads the file and the new content is not present? Can you provide appropriate payloads for that testing and show your network trace for those calls? Are you sure no one else is calling those endpoints while you’re testing? What do you see if cat or jq the files during the manual verification step?


#10

I’m not sure what you’re saying on the last part, but I do is I click a button on a chrome extension and it will post a cookie to /c. I wait for the “null” error on the write file and then start up my game and post to the server. I console log when it finds the changed file and it shows the last 2 fields as gone, and I refresh the app, see them there in the json, and try again to get the same situation.


#11

What exactly do you mean by that?


#12

In the callback of “writeFile” it provides an error if there is any. I console.log(error) and it says null, saying it successfully saved.


#13

I see you changed quite a bit on /c - what ended up being the problem?