operation.build different from SOAP data sent

[superlou]

When calling puts operation.build for a SOAP, the data sent by operation.call is different.

puts operation.build               # First XML listing
response = operation.call     # Second XML listing (sent SOAP captured by Wireshark)

The following is the result of the build method:

<env:Envelope xmlns:lol0="http://AutodeskDM/Services/ItemService/1/20/2011/" xmlns:env="http://schemas.xmlsoap.org/soap/envelope/">
  <env:Header>
    <lol0:SecurityHeader>
      <lol0:Ticket>my_ticket</lol0:Ticket>
      <lol0:UserId>my_user_id</lol0:UserId>
    </lol0:SecurityHeader>
  </env:Header>
  <env:Body>
    <lol0:FindItemRevisionsBySearchConditions>
      <lol0:searchConditions>
        <lol0:SrchCond PropDefId="264" SrchOper="1" SrchTxt="7103-1201" PropTyp="SingleProperty" SrchRule="Must"/>
        <lol0:SrchCond PropDefId="59" SrchOper="1" SrchTxt="Work" PropTyp="SingleProperty" SrchRule="Must"/>
      </lol0:searchConditions>
      <lol0:bRequestLatestOnly>true</lol0:bRequestLatestOnly>
      <lol0:bookmark></lol0:bookmark>
    </lol0:FindItemRevisionsBySearchConditions>
  </env:Body>
</env:Envelope>

This is the SOAP message sent (captured by WireShark):

<env:Envelope
    xmlns:lol0="http://AutodeskDM/Services/ItemService/1/20/2011/"
    xmlns:env="http://schemas.xmlsoap.org/soap/envelope/">
    <env:Header>
        <lol0:SecurityHeader>
            <lol0:Ticket>
                my_ticket
                </lol0:Ticket>
            <lol0:UserId>
                my_user_id
                </lol0:UserId>
            </lol0:SecurityHeader>
        </env:Header>
    <env:Body>
        <lol0:FindItemRevisionsBySearchConditions>
            <lol0:searchConditions>
                <lol0:SrchCond/>
                <lol0:SrchCond/>
                </lol0:searchConditions>
            <lol0:bRequestLatestOnly>
                true
                </lol0:bRequestLatestOnly>
            <lol0:bookmark>
                </lol0:bookmark>
            </lol0:FindItemRevisionsBySearchConditions>
        </env:Body>
    </env:Envelope>

The attributes in the SrchCond elements are missing on the actual message sent. This may be related to #509. Is it possible that it's related to the WSDL, even though the SOAP looks correct in the build method?

[superlou]

Tracked down what was causing the symptom, though I don't know the cause. In the current master, if operation#build is called multiple times, the result is different. The first result of build contains the attributes, and all further calls are missing them. My code works if you only do operation.call without having first done operation.build.

[tjarratt]

Hmm, that's interesting. Would it be possible to submit a simple testcase that reproduces this issue?

[superlou]

Sorry, just got back to a place where I have computer access. I'm not too familiar with righting rspec tests. Is there a similar test you could recommend that I can try modifying?

[tjarratt]

Absolutely. This sounds like a legitimate bug in Savon that should be fixed. I'd like to do it, but I'm already stretching myself thin between work and my own projects.

I think you could add a test to Savon in the spec/operation/build.rb suite, possibly nested under describe('#build'). The approach would probably be to read in a WSDL, stash off the result of operation#build and then assert that calling it again gives you the same string.

[ashrocket]

I encountered the same bug. 5 hours I'll never see again. (Don't you love it when debugging introduces new false bugs?)
I was putting body content to stdout by executing @operation.build before making the @operation.call

Then while debugging in the httpclient clode just before

      do_request(method, uri, query, body, header, &filtered_block)

I checked out body in the debugger, and yes, there no attributes set.
The XML structure was corrected but all XML attributes were missing.

[superlou]

@ashrocket, the nefarious puts is how I ran into the issue. We've been working around it by making new operation objects, but that seems like a bad habit.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

This issue is now closed due to inactivity. If you believe this needs further action, please re-open to discuss.