Bug 855449

It may be the case that AFTER never works, actually, regardless of match.

condor-aviary-7.8.3-0.1.el5

100% reproducible

1) Install condor with condor-aviary and submit multiple jobs.

2) In my testing, I configured Aviary to use the locator so I have to retrieve the endpoint for the QUERY_SERVER (but known endpoints might be easier for testing)

# cd /usr/share/condor/aviary/
# export PYTHONPATH=`pwd`/module:$PYTHONPATH
# ./locator.py --type=CUSTOM
CUSTOM | QUERY_SERVER | query.com | http://somehost.redhat.com:39903/services/query/

3) Get the list of submissions to confirm that Aviary knows about the jobs:

# ./submissions.py --u=http://somehost.redhat.com:39903/services/query/getSubmissionSummary
[(SubmissionSummary){
   id = 
      (SubmissionID){
         name = "cat"
         owner = "admin"
         qdate = 1343740287
      }
   status = 
      (Status){
         code = "OK"
      }
   completed = 4
   held = 0
   idle = 0
   removed = 3
   running = 0
   suspended = 0
   transferring_output = 0
 }
...

4) Run a search with scan mode BEFORE and a large qdate.  I used 2000000000 because it's out in the future, so everything is "before".  This works.

[root@somehost aviary]# ./submission_ids.py --qdate=2000000000 --mode=BEFORE --size=1024 --u=http://localhost:39903/services/query/getSubmissionID
(reply){
...
}

5) Run a search with scan mode AFTER and use 0.  This fails with no data:

# ./submission_ids.py --qdate=0 --mode=AFTER --size=1024 --u=http://localhost:39903/services/query/getSubmissionID
(reply){
   remaining = 0
 }

6) Search with a value from the original submission list, just in case Aviary can handle an existing date but not 0.  Also fails:

]# ./submission_ids.py --qdate=1343740287 --mode=AFTER --size=1024 --u=http://localhost:39903/services/query/getSubmissionID
(reply){
   remaining = 0
 }

Expected results:

For scan mode AFTER, Aviary should handle any legitimate qdate value including 0.  If there are jobs in the history that have qdate >= target value, they should be returned.  According to code in the test program /usr/share/condor/aviary/submission_ids.py, the legal range for qdate is 0 to maxint:

if opts.qdate and (long(opts.qdate) > sys.maxint):
    print 'Invalid input: Qdate is larger than system max integer'
    exit(1)

I am assuming that negatives are legal, and have the same effect as 0.

Tested on RHEL 5.9/6.4 x x86_64/i386 with
condor-7.8.7-0.6.el6_3.x86_64
condor-aviary-7.8.7-0.6.el6_3.x86_64
condor-classads-7.8.7-0.6.el6_3.x86_64
condor-wallaby-base-db-1.25-1.el6_3.noarch
condor-wallaby-client-5.0.4-1.el6_3.noarch
condor-wallaby-tools-5.0.4-1.el6_3.noarch
python-condorutils-1.5-6.el6.noarch
python-qpid-0.18-4.el6.noarch
python-qpid-qmf-0.18-12.el6_3.x86_64
python-wallabyclient-5.0.4-1.el6_3.noarch
qpid-cpp-client-0.18-12.el6_3.x86_64
qpid-cpp-server-0.18-12.el6_3.x86_64
qpid-qmf-0.18-12.el6_3.x86_64
qpid-tools-0.18-7.el6_3.noarch
ruby-condor-wallaby-5.0.4-1.el6_3.noarch
ruby-qpid-qmf-0.18-12.el6_3.x86_64
ruby-wallaby-0.16.1-2.el6.noarch
wallaby-0.16.1-2.el6.noarch
wallaby-utils-0.16.1-2.el6.noarch

and it works. --> VERIFIED

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHSA-2013-0564.html