ICRAR / ngas

63%

master: 69%

LAST BUILD ON BRANCH v11

branch: v11

CHANGE BRANCH

x

Reset

• v11
• 98-query-ignore
• NGAS-163
• aiosmtpd
• avoid-installing-bsddb3-in-py27
• bbcp_fixes
• c_client_warning_fixes
• centos7-compatibility-changes
• clone-fix
• clone-order-fixes
• correct-janitor-init
• correct-logging-c
• coverage-stability
• direct_sql
• doc-updates
• docs-fix
• document-future-removal-of-27
• fits_optional_arcfile
• fix-requests-dependency-specs
• fs-monitor
• fs-monitor-fixes
• github-actions
• improve-register-error-message
• issue-103
• issue-13
• issue-38
• issue-44
• issue-50
• issue-51
• janitor-thread-startup
• macos-hostnames
• macos-travis-fix
• macos-travis-update
• master
• netifaces-fix
• next
• no-create-venv
• none-reg-parameters
• partner_sites
• plugins-importing
• py311
• py39
• python-client-improvements
• relaxed-netifaces
• release-12.0
• remove-2.7-builds
• remove-test-generic-registration-plugin
• requests-pinning
• richer-archiving-event
• separate-test-servers
• servers-flag
• small-improvements
• smtp-testing
• stream-proxy-request
• subscription-def
• subscription_thread_ng
• travis-errors
• travis-fixes
• travis-focal
• update-travis-matrix
• uwe-fixes
• v12
• v12.0
• various_improvements
• volumes

Build # 343

Build Type

push

travis-ci

Committed by rtobar

Commit Message

Preventing TypeError during date comparison

The type of lastSchedule up to this point is either NoneType or str,
but on the other hand lastDelivery is a float (the type we use
internally to hold date/times). These two values are compared for order,
and while python2 happily compares strings v/s floats, python3 refuses
to do so and bombs out with a TypeError.

Because the subscription code is so convolved, it's a bit difficult to
fix this at the very source of the problem, but ensuring the correct
data representation just before the comparison is sufficient.

This problem was obviously not caught by our unit test suite because the
conditions to trigger it were not coded into any of them. I'm thus
adding a new unit test that reproduces the original problem, and that
will ensure this doesn't happen again.

This patch solves #6.

Signed-off-by: Rodrigo Tobar <rtobar@icrar.org>

Run Details

19406 of 30656 relevant lines covered (63.3%)

2.66 hits per line