I'm working on adding server authoritative lag compensation to my FPS game - specifically by using raycasts for hitscan bullets. My algorithm is as follows:

  1. Clients send inputs to the server
  2. Process movement and save all player locations
  3. For each "shooting" input received,
    3a. interpolate player positions to the time the shot was taken (based on previously saved locations)
    3b. Run a raycast while players are in those positions
    4c. process hits
  4. revert players to saved locations from step 2
  5. send all important info to clients

After struggling with this on and off for like - years (lul) - I found someone that could tell me that in Godot "Physics bodies will only be in their position on the next frame". This didn't make sense to me at first - but now does completely. If this is the case - I can't do raycast based lag compensation at all because all the times I interpolate player positions in step 3a they aren't actually moving at all. And based on how this works - I can't let the server process n frames to update player positions for every n shots it needs to process as that would freeze the game for n ticks.

Anyone have any insight on how I could do raycast based server authoritative lag compensation in Godot?

I think the way this is typically done these days is to use "rollback," meaning both the server and the clients process inputs, with the client resyncing to the server's game state whenever there's a discrepancy. So you could use the raycasting method you describe above, you'd just need to be able to retcon hits if the server got a different result than the client.
https://sea.ign.com/street-fighter-next/188810/news/what-is-rollback-netcode-and-why-is-it-so-important-for-fighting-games

That is essentially what I am doing - instead of rolling back though inputs to put the players in position I interpolate the player positions based on saved state (or snapshots).

Based on my understanding, neither way will work with because players only actually are "moved" in the physics world upon the "next" physics tick - and the physics based raycast operates within the physics world. So in my current implementation where I move the players around for each shot (raycast) to run - the players don't actually move and I'm just running raycasts against the players' original location.