Previously I was working on a complete reverse migration (Or Staging Refresh) system and it wasn’t working right. But I didn’t need to do the big reverse migration so I put it on the back burner. Today I’m returning to my reverse migration troubleshooting and I got the following error (on several tries actually)
So that’s a new one to me. My search results here aren’t coming up with an answer to what causes the “Maximum call stack size exceeded.” Chat GBT tells me “occurs in JavaScript when too many function calls are nested, causing the call stack to exceed its maximum size. This can happen due to several reasons:” And then gave me server al examples.
The error occurred when I sucked files directly from the production server to the staging server with a REPLACE operation selected. The follow up was to be I migration of schema from a clone file build on the staging server, but we didn’t get to that part.
Ironically, in the past I was able to get the replacements in place, but the schema would fail…
That error is happening when we get the database info. When we get the database info we are reading the filesystem to get the file-paths for the files. I suspect what is happening here is that you have some sort of circular file structure that causes our recursive file tree reading to read forever, and at some point the call stack gets exceeded. I’m pretty sure I can fix this on our side since that doesn’t really need to be recursive. I’ll include a fix in our next version. This issue would likely be happening in version 4.5.0 as well.
For right now you can try hunting down whatever symlink or shortcut is causing the nested structure and get rid of it. It could be in any of your database folders, we check all of them to make sure we find the files.
Interesting. I’m investigating further. But when I did the a simple normal migration in the regular direction with one file, I got the same error. Now I did observer that my test staging server is 2024 and my test production server is 2023.
Perhaps it’s because I’m working with a fractured rib right now.
Yeah thats calling the same recursive code. I’ll get a fix put together for that. I suspect we will be releasing a small patch fix in the next week sometime with a few smaller fixes for 4.6.0, I’ll make sure its included in that.
I was able to reproduce this by introducing two symlinks into my database folder that both referenced back into the same database folder. It looks like it only happened for me when the nested folder was approaching 120 folders or so, which I would be surprised if that was happening naturally. If you have a shortcut or symlink in one of your database folders that you can remove then I would recommend doing that. Otherwise, I’ll get a fix our soon. Thanks for the report Fred!
OK! (read with energetic voice)
This morning I logged into the test server to see what I may see, and… there are no symlinks on the data drive or the backup drive. BUT, I did notice that there were folders. These were the usual Removed_by_fms, and RC_Data_FMS, and …OttoFMS. What? That probably got copied over by accident–remember this is a testing server.
So, (read with less energy) I deleted the rouge OttoFMS folder, and cleared out the Removed_by_FMS folder, And it worked.
Nevertheless, I’m delighted to find yet another bug even if it is very minor (and my own fault).
Oh yeah that OttoFMS folder has a bunch of symlinks in it, glad we found that. Thanks again for the report Fred, the next version will make sure this doesn’t happen again!
This issue is resolved in version 4.6.1, which removes the recursive code call in favor of simply reading a couple layers of the database folders. Thanks for the report Fred!
