TypeError: object of type 'NoneType' has no len()

[clemens]

The TracTicketChangelogPlugin (as of version 1.2.0.1dev, TRAC HACKS revision r18070, 2021-03-16) may cause an error if the (SVN) repository is not properly synchronized:

TypeError: object of type 'NoneType' has no len()

Analysis

The stack trace points to line 221 of ticketlog/web_ui.py. One must not use the length function len(message) if the object does not exist.

    rev, author, timestamp, message = key
    if self.max_message_length \
            and len(message) > self.max_message_length:
       message = shorten_line(message, self.max_message_length)

In some odd cases message does not exist (i.e. None). In my situation this happened because in the ticket_revision database table SVN revision were listed, which did not really exist in the SVN repository anymore. The reason for this was because I replace the SVN repository with another one, but forgot to resync the database.

Workaround

Of course one can cure the problem by syncing the database:

trac-admin <ENV> ticketlog sync

Nevertheless, I believe that the code should be robust to deal also with unusual situations. Some people (like me) may simply forget the sync, and should not be "punished" with a TRAC error.

Proposed Solution

I would simply insert a plausibility check to test if the message object is None. We cannot continue in this case:

    rev, author, timestamp, message = key
    if message is None:
        return revisions;
    if self.max_message_length \
            and len(message) > self.max_message_length:
        message = shorten_line(message, self.max_message_length)

I will provide a patch for this...

[clemens]

stack trace of the error

[clemens]

patch file with proposed minimal solution - as described above

[clemens]

My proposed patch​ would simply insert a plausibility check to test if the message object is None. In my situation this was enough to avoid the error 'NoneType' has no len(). Makes up some kind of minimal solution.

However, it might make sense to do plausibility checks for all the objects (rev, author, timestamp, message) or maybe even earlier e.g. check the key variable. This is the decision of the code owner.

P.S.
Great plugin!
We use in in all our projects and our people are trained to make ticket references in their commit messages.