Similarly: renaming (or deleting) a node causes job history entries for jobs built on that node to say they were built on the "master" node instead.

When I rename a job in current version (1.496) the job history disappears immediately, but if I restart the Jenkins service the history reappears under the new job name. Internally, the history files are being moved properly but jenkins doesn't re-load the data into the new project.

This one bit us hard today.

I have 1.514. After renaming jobs give it sometime to work out the disk files (in my case ~5 min), then click on "Manage Jenkins / Reload Configuration from Disk" and the history was reloaded OK.

It looks like a duplicate, but more than one year has passed: JENKINS-18678

Manually reloading defeats the purpose of automated builds. Also, in my case, I cannot rely on "waiting 5 minutes": it has to be deterministic and it cannot be based on waiting "long enough".

If a rename requires a reload from disk, then it must do so autonomously without disturbing anything else (current builds, pending builds, etc.).

The next question that comes to mind is what about dependencies? What if the job I rename is used by another job, say by the Copy the Artifact? Does the rename action take care of updating that other job too?

FYI: The renaming of the jobs, in my case, was propagated to other jobs using it. While reloading from disks it did not disturb running jobs.

The rename action does take care of updating jobs that use Copy Artifact and dependencies.

You only need to reload the configuration manually from disk after you have renamed a job, as far as I can see. After you have done that, your history is reinstated. So this bug is frightening, because it looks as though the history has been lost, but it turns out to be harmless.