That kind of rebase is great, because you are applying your work on top of the master branch (i.e., making the history read as it should be, that your set of commits was added on top of master). That's why git says it's "replaying" your commits on top of it. That usually works because you and master have a common previous point of reference.
If the master branch went back and changed something before that common point of reference, things get more confusing. If you want to see this yourself, checkout a separate branch, rebase interactively and make a big edit in the past. It's much more painful to add on top of that successfully with the first branch (git will want to do a merge commit) because now the history has diverged between them. (and if you use CI, you might notice that when you rebase a wip topic branch locally, git tells you things like "You are 10 commits behind and 5 commits ahead".
If the master branch went back and changed something before that common point of reference, things get more confusing. If you want to see this yourself, checkout a separate branch, rebase interactively and make a big edit in the past. It's much more painful to add on top of that successfully with the first branch (git will want to do a merge commit) because now the history has diverged between them. (and if you use CI, you might notice that when you rebase a wip topic branch locally, git tells you things like "You are 10 commits behind and 5 commits ahead".