| Summary: | ASTERISK-25430: Testsuite: batched rls subscription failure | ||
| Reporter: | Ashley Sanders (asanders) | Labels: | |
| Date Opened: | 2015-09-28 11:20:39 | Date Closed: | 2015-11-24 08:30:39.000-0600 |
| Priority: | Major | Regression? | |
| Status: | Closed/Complete | Components: | Tests/testsuite |
| Versions: | Frequency of Occurrence | ||
| Related Issues: | |||
| Environment: | Attachments: | ( 0) full-ast1.txt ( 1) full-run_1.txt | |
| Description: | The AsteriskTestSuite tests/channels/pjsip/subscriptions/rls/lists/nominal/presence/batched/basic is failing with the following error:
ERROR[19504]: rls_integrity:378 fail_test: Unexpected number of parts (2) in multipart body See https://bamboo.asterisk.org/bamboo/browse/AST-ATTSCD-C664TE-797/test/case/12354891 for more information. | ||
| Comments: | By: Ashley Sanders (asanders) 2015-09-28 11:22:35.812-0500 From [~kharwell]: Looking into this a bit there are a few of additional things to note: 1. The test does not fail on the agents every run. However, I can pretty much get it to fail every time on my machine. 2. The Asterisk log shows all expected SIP NOTIFY messages being sent. 3. The test is checking up to 5 lists versions. The rls_integrity.check_integrity function seems to be failing when checking the second pass through (list version 1). Meaning list version 0 passes okay, but the next check is failing. After adding a small amount of debug code it looks like on the second pass through the incoming packet contains the data for the last expected NOTIFY (list version 4), thus the mismatch on the multipart body. From [~jcolp]: Per Kevin Harwell - he did some light investigation and it looked as though Asterisk was sending out the right stuff, but pcap may not have been picking it up. | ||