Fossil Forum
Post: I think I found a bug around ticket ids.
Hello,
I have just noticed that whenever I close a ticket, ticket id (not the ticket hash) changes. I am not sure if it is the expected normal behavior but in my mind, a field name with "id" in it, should not change its value.
How to reproduce the problem:
cd /tmp
mkdir fossil_test
fossil init --project-name 'fossil_test' --project-desc 'investigate ticket number increment' ../test_fossil_repo.fossil
cd fossil_test/
fossil init --project-name 'fossil_test' --project-desc 'investigate ticket number increment' ../test_fossil_repo.fossil
touch a
touch b
fossil open --keep ../test_fossil_repo.fossil
fossil add a b
fossil commit -m 'initial commit'
fossil ui
At this point, using your browser (this is what I did), * create 2 tickets. * Notice ticket_ids are 1 and 2 respectively (as expected) * edit 1st ticket and close it * Notice ticket_id of ticket is bumped up to 3.!
Thank you.
Notice ticket_id of ticket is bumped up to 3.!
The ID you're looking at (but should not be) is the "blob.rid" from the db. Those are internal and not stable across clones (your rid 3 might be my rid 392).
It is possible that the ticket interface exposes those IDS, but it should not - please let us know if you see a link which is passing those around.
Having recently started messing with tickets in a small repo used just for that purpose:
What may be confusing the OP is the first line of the view ticket page which says for example:
Ticket Hash: 2f52cc34f86be9d81cc8d0a9fd33afa8d68cc908 (3)
(maybe in a different skin it might say 'id' instead of 'hash'?)
The thing is - what is that number (3) at the end? It can indeed look like a ticket number, because when you start you get 1,2,3 etc. at least if you aren't doing anything else with the repo. It's when you edit a ticket that you realise that isn't what it is, because it changes. It doesn't correspond to any of the RIDs of the ticket changes.
The only place I can see RIDs actually displayed as such is in the ticket history. They are not links.
For the OP: like many things in Fossil, the 'id' of a ticket is its hash, or a long enough prefix of the hash for it to be unique. In the example above '2f5' would do it. The (3) is not part of the hash. The ticket hash is effectively a random number: this allows many users to create tickets in one shared repository without having to co-ordinate to agree on the next ticket number.
Trevor
Thank you both for your time and explanations.
I am not sure if we are talking about that same thing. I think I cut corners on my first go at the problem definition. Please bear with me and let me give it another go.
Steps to reproduce the problem:
$ cd /tmp
$ mkdir ticket_bug
$ cd ticket_bug
$ fossil init --project-name 'ticket-bug' --project-desc 'possible bug in fossil ticketing system' ../ticket_bug.fossil
$ fossil open ../ticket_bug.fossil
$ fossil ui
- Using the ui, go to Tickets > All Tickets > Edit
- Notice table schema:
CREATE TABLE ticket(
tkt_id INTEGER PRIMARY KEY,
tkt_uuid TEXT UNIQUE,
tkt_mtime DATE,
tkt_ctime DATE,
type TEXT,
status TEXT,
subsystem TEXT,
priority TEXT,
severity TEXT,
foundin TEXT,
private_contact TEXT,
resolution TEXT,
title TEXT,
comment TEXT
)
- Now update All Tickets report and add tkt_id to the table as follows:
SELECT
CASE WHEN status IN ('Open','Verified') THEN '#f2dcdc'
WHEN status='Review' THEN '#e8e8e8'
WHEN status='Fixed' THEN '#cfe8bd'
WHEN status='Tested' THEN '#bde5d6'
WHEN status='Deferred' THEN '#cacae5'
ELSE '#c8c8c8' END AS 'bgcolor',
tkt_id,
substr(tkt_uuid,1,10) AS '#',
datetime(tkt_mtime) AS 'mtime',
type,
status,
subsystem,
title
FROM ticket
Please note that tkt_id is primary key to this table.
- Make sure to Apply Changes
At this point there should be no tickets in the system.
-
Create 2 tickets
-
Hit again Tickets > All Tickets for the report
1 4dba76e2e4 2026-08-26 08:32:37 Code_Defect Open ticket 1 edit
2 12d2461dd2 2026-08-26 08:32:49 Code_Defect Open ticket 2 edit
Notice that first column shows the tkt_id. 2nd column has tkt_uuid and may and will change for your case, same for 3rd column data.
-
Now edit first ticket and close it.
-
Hit again Tickets > All Tickets for the report
2 12d2461dd2 2026-08-26 08:32:49 Code_Defect Open ticket 2 edit
3 4dba76e2e4 2026-08-26 08:35:41 Code_Defect Closed ticket 1 edit
Notice tkt_id (primary key) for the ticket 1 has been replace with 3
Well, this all could be part of the design and how the internals of ticketing mechanism works. All I am saying is I found it surprising to see that a primary_key to an existing record changes.
Thank you.
This goes back to what I was saying about tickets having a history.
tkt-id = 1 is the original version of 'ticket 1'
tkt-id = 2 is the original version of 'ticket 2'
tkt-id = 3 is the updated version of 'ticket 1'
When you modify ticket 1 Fossil does not update the original record, it creates a new one and links them together.
If you were now to create a 'ticket 3' you would probably get a tkt-id = 4
tkt-id is not included in the report by default because it is essentially meaningless to the user.
Look at an individual ticket and then click on the History button at the top.
Now it makes sense. It actually aligns with Fossil's "don't delete anything but keep everything" philosophy too. Thank you for the clarification. Much appreciated.