We build products which often integrate with third party systems. Sometimes these systems error, which in turn causes our system to error. For example, we call a web service when a user updates their data after we've saved to our own database. While testing, the service on the other end is not functioning correctly.
I can see both sides; on one hand the software won't work until the service is fixed, and so we need to track that somehow. On the other, there's nothing we are going to do that will resolve the defect and having a critical defect in our system sitting there seems to be a waste (and may concern others looking at the tracking system wondering why we have defects we're not acting on).
My question is, should these be tracked as defects in our tracking system, or should our QA people not be logging defects if they know this is the reason (typically they do as they'll ask me if unsure)?
Edit: A few people are making assumptions. The web service were calling is developed by another shop, and we are both being paid by the same client to integrate our systems. Our UI handles the error correctly it doesn't show a ysod. It tells the user they cannot change their account at this time. The defect being reported by our qa team is of course that the user ought to be able to change their account, but they don't know if the issue is something we need to fix or the other company. According to our requirements, we cannot save the users changes if the service call fails. Its been decided that these failures should be uncommon enough that this design is ok. Were also working with the other company to iron out some details that have come up during our testing.