Please give us your username, the time of your edit.
Also give us an example of changes you added to this article.

http://en.wikipedia.org/w/index.php?title=Meanings_of_asteroid_names_%285001-5500%29&diff=18712419&oldid=18693914

I see change by user Eilthireach adding identifications in this article.

angus wrote:

I was unable to get back to you on this. It has happened again
today. At 1530 hrs I edited Meanings of asteroid names 16001-17000
and the changes I made to nos. 16817 and 16847 were not there when
I went back in at 1900 hrs. The changes are text additions, giving
explanations for the names assigned to each asteroid. The
identifications replace the asterisks which can be seen against any
entry that does not have an explanation for its designation.
I am user Eilthireach

This change?

http://en.wikipedia.org/w/index.php?title=Meanings_of_asteroid_names_%2816001-17000%29&diff=19603319&oldid=19407963

angus wrote:

No. These were my edits, but not the ones that have disappeared. As
I reported in "Additional comment #2", the edits were to nos. 16817
and 16847. As usual, I made changes (added identifications) and
saved the edits, and when I returned three hours later, the edits
were gone

Were they in fact saved, or did that display as a page preview?

angus wrote:

Thanks for the reply. I do indeed always go through the preview
stage before saving an edit, and, since there is a prominent
warning at the top of the Preview page, I would not have left the
site at that stage.
If you cannot find the edit in the logfiles, then I can only
presume that there must have been a glitch in my broadband
connection. I am just concerned that I am spending a lot of time
researching these identifications (and, of course, working on other
articles) and hope that that work is being properly saved. I can
check on -some- of the articles but don't have time to check -all-
the edits on -all- of the articles! You have to take it on trust
that the system works.
Can I have confidence in the system? Has that bug really been
corrected that we were all warned about when the wiki software was
upgraded?

If a page is successfully saved, it will stay saved.

Be aware that a save operation (clicking on the 'save' button) may fail for
various reasons:

• Edit conflict requiring manual resolution
• Session data expiration requiring confirmation or relogin as a security check
• Database congestion of lock conflict producing a database error
• Other transient error

Can you confirm that none of these occurred -- that you did not receive an
error message, or a preview, or any other such, but that you were presented
with a successful save and the version of the page as you wished to leave it?

Can you clarify about "the feature" and "the problem" you speak of? What
feature is this? What is the problem with it? What does it have to do with last
month's upgrades? Who "warned" you about it, and what specifically was this
warning?

Please be as specific as possible in documenting this problem.

I have today twice lost edits to [[Time management]], most recently at 18:30EDT. Earlier incident around 14:00EDT. The changes included text and numerous tags.

I am willing to play along for a while, but if there is no resolution I'm not going to be an active contributor to Wikipedia. Is there some practice I can follow that will eliminate the risk? It appears that I will have to do any high-volume work off-line and cut-and-paste it in. Can I count on that working ?

I can't find any sign of edits at those times in the database. My guess would be that some glitch is causing the edit to fail to save properly, but the user interface still is redirecting you to the final page view, hiding the error message.

If you don't look closely enough to see that your change didn't get saved, it's hard to tell anything bad happened.

Unfortunately our database error logs are currently stuffed up with an unrelated problem so I'm limited in my diagnostic tools. :(

(In reply to comment #9)

I can't find any sign of edits at those times in the database. My guess would
be that some glitch is causing the edit to fail to save properly, but the user
interface still is redirecting you to the final page view, hiding the error
message.

When writing the ApiRollback module, I discovered that Article::rollback() ignores certain obscure errors. This case may be similar.

Is this still an issue?

doesn't seem so