Re: email issue creation not in sync

Tonu, you describe only that you copied the data of the tracker
directory. You do not mention how you migrated the database. Also
interesting would be what your database backend is.

If you incorrectly migrate the database it can happen that the counters
for issues (in the DB) are not correctly set to the highest issue
number. This would mean that on creation you would (try to) overwrite an
existing issue. The description of your problem looks somewhat like
this, but since it doesn't seem to happen via the web-interface I'm not
sure.

This looks like the problem described above:
> When attempting to create a new issue by emailing the email address that
> the tracker checks, the new issue did not created.  However the tracker
> replied that the issue did get created, but the link in the message
> references an incorrect issue.  In this email below issue #519 is something
> entirely different - https://www.screencast.com/t/n0qBOH2Om7vC .
> When replying to tracker generated email I got response from the tracker:
> The node specified by the designator in the subject of your message
> ("521") does not exist.
> 
> Subject was: "Re: [issue521] Another issue for testing email"
> 
> When in fact the issue #521 does exist - see image at
> https://www.screencast.com/t/rpfFp4Bi .

Are you sure this problem (that your tracker tries to overwrite an
already-existing issue when you try to create a new one) does *not*
happen when you create an issue via the web-interface?

There were several changes between 1.5.X and 1.6 that you should find
documented in doc/upgrading.txt
One change that is relevant here is the change how backends are
configured. This has moved from a file in the db directory to a
configuration item in config.ini.

But I don't think this is the reason for the behaviour you're seeing
because everything seems to work via the web interface.

When processing a change to an issue (or creation of a new one) roundup
has a two-stage process where first auditors from the detectors
directory are run, then detectors. One detector for example is
responsible for sending out nosy emails.

Now one would expect that after the auditors are run, the database
commit happens. This is not the case for historical reasons. So it can
happen that *after* the nosy reactor is run (which sends out email)
something bad happens (a traceback) and the issue, although mail was
sent for it, is never created/changed and the changes are rolled back in
the database.

I think this is happening here.

You should be able to debug this by running the roundup-mailgw on the
command line and observing if a traceback occurs.

>    2. The roundup versions could be different between the old server and
>    the new server.  Roundup on the new server is running version 1.6.  Roundup
>    on the old server was installed about 1.5 years ago and could be running
>    Roundup version 1.5.  Is there a way to verify which version of roundup I
>    am running?  Could not find this in Roundup documentation, sorry!

You can find out the version of roundup and python used with
roundup-admin -v

Ralf
-- 
Dr. Ralf Schlatterbeck                  Tel:   +43/2243/26465-16
Open Source Consulting                  www:   http://www.runtux.com
Reichergasse 131, A-3411 Weidling       email: [email protected]