WEEKDAY_DELIVERY

There have been a few reports of this on ubercart.org, but only in the past 3 months. I have never been able to reproduce the error - this module has been released for 16 months and running for longer than that on my server without the error ever happening to me and without any reports of this problem from the community until recently. Also, the schema, RateAvailableServicesService_v2.wsdl, as well as the FedEx documentation and example code, says it's right. So I have to conclude there's something else going on here. I suspect something changed on the FedEx side, which is why this problem only cropped up recently. Perhaps the schema is wrong, or FedEx's implementation is flawed, or something of that sort. I don't know why it only fails for some people not others, and I haven't investigated whether removing this option causes side effects (weekend delivery costs more, so are the quotes greater if weekday delivery is not set and the expected transit time has the package arriving on a weekend?).

Regardless, I prefer to put my efforts into updating the module for the V6 API (see the 6.x-2.x-dev release) because I expect that's better implemented and supported on FedEx's side. If you can figure out the conditions under which this option fails and determine that the fix doesn't break other users of the module, I will make the change.

On the Ubercart site, it looks like a lot of people are having this problem. I just installed this module and it echoed out this error immediately. I never got it to work.

Since you said you are not going to maintain v1, can you give us an estimate for when we might be seeing v2?

This issue is marked "needs more info" because I can't reproduce it, so I can't debug it. As yet, no one has been willing or able to provide any more details as to why the issue arises in contradiction to the FedEx documentation, WSDL schema, and example code. A simple workaround (comment out one line of code) is posted both here and on Ubercart.org for those experiencing the problem, but it's hardly a "solution" since the cause is unknown - at best it's an avoidance of the issue.

I didn't say I'm not going to maintain v1. I said I would rather spend my time improving the new version of the module that uses the latest FedEx API rather than blindly flailing at this issue, because it's likely this problem is on FedEx's side and is resolved using their latest code.

Version 6.x-2.x-dev has been posted on the project page since before the initial post in this thread.

Sorry, buy "seeing v2" I meant seeing a release of version 2. The project page mentions that the version is undergoing heavy development and shouldn't be used on a production site, so I was mostly curious as to when you expect to be able recommending using it?

For what it is worth, I removed v1 and used the v2 and it worked fine. The errors I was experiencing are gone. I haven't looked at the code at all, so I don't know what changed but I would suspect that the error is being generated from the module's code rather than FedEx based on this fact.

My concept of a release, even a development release, is code that is working. I never make a release when there are known bugs, however development releases may have some unimplemented features.

The "next few weeks" in which I said I will be doing heavy development have since passed, and the 6.x-2.x-dev release is not changing much anymore. I will update the project page to reflect this. It will stay a development version for a while to allow people to use it and find bugs. (It has been running without a problem on my own site for about three weeks now.) If I don't receive any bug reports for a while I will turn it into an official release.

Good to know, I've been happy with v2 thus far. Thanks.

Seems to be a non-issue at this point. Feel free to re-open the issue if the problem persists.