ajax operation failed unexpectedly
P粉511985082
2023-08-28 16:25:52
<p>我们在网站上的许多地方使用了 ajax。一个实例有时会表现得不规则，就像 ajax 调用失败一样。它仅在一个特定位置 - 所有其他位置都按预期工作。</p>
<p>发生故障时，用户会收到操作失败的错误消息。</p>
<p>我们无法重现该故障。它总是只适合我们。大多数用户没有遇到这个问题。少数确实这样做的人有时会报告说他们稍后再试一次并且成功了。</p>
<p>我们可以通过重命名ajax脚本来模拟失败。然后，当尝试操作时，ajax 调用失败，我们收到相同的错误消息。然而，我们没有任何理由相信该错误是由于无法访问 ajax 脚本引起的，尽管有可能。如果是这样的话，那么我们的其他 ajax 脚本也会出现同样的问题。</p>
<p>我们已经想出了一个解决方法。如果用户在尝试操作之前进入隐身模式，则可以避免该问题。</p>
<p>隐身模式解决方法表明它可能与 cookie 有关。因此，我们尝试以某种方式干扰 cookie，以尝试重现该问题。什么都没有成功。</p>
<p>为了帮助排除故障，我们在错误消息中添加了额外的诊断信息，但到目前为止，除了类似于“错误”的信息之外，还没有任何结果。下面是一些代码，显示了我们如何尝试获取更多信息：</p>
<pre class="brush:php;toolbar:false;">error: function (jqXHR, textStatus, errorThrown)
{
// alert('read-unread error');
ajaxError('Read-Unread', textStatus, errorThrown); // TODO comment out to suppress the error reporting
},</pre>
<p>为了完整起见，我在下面包含了完整的 JavaScript 函数。</p>
<p>建立一个简单的测试环境来演示问题效果并不好，因为它会过于简化真实环境，从而破坏了其测试价值。我们认为唯一合理的测试是模拟用户正在做的用例。不幸的是，这很复杂，因为它涉及在我们的系统上创建个人资料，尝试使用该系统与其他成员进行通信，从其他成员那里获得一些响应通信，然后尝试回复此类通信。这会重新创建用例以及发生故障的位置。不幸的是，我们再次怀疑它仍然永远不会触发我们的失败——玩具系统也会“正常工作”。</p>
<p>如果每次都发生在每个用户身上，那将是一回事，但事实并非如此。某些时候只有部分用户使用，并且仅用于我们网站上众多 ajax 使用中的一种。一旦它开始发生，至少在一段时间内该用户可以重复。</p>
<p>我的问题：</p>
<ol>
<li><p>我们如何创建一个精简版本的环境，以便我们可以让 stackoverflow 社区值得一看，而不是模拟我们网站的使用？</p>
</li>
<li><p>“隐身模式”解决方法是否可以提供任何见解来了解出现的问题？</p>
</li>
<li><p>除了诊断在大多数情况下都能正常工作的代码之外，了解其他 Ajax 故障模式也会很有帮助。举个虚构的例子，比如“某些系统太慢，ajax 超时”。</p>
</li>
</ol>
<p>[JavaScript 函数。注意：由于某种原因，我无法将函数的前几行放入代码标记中。]</p>
<pre class="brush:php;toolbar:false;">function toggleReadUnread(usertypeid, opp_user_label_short, principalid, repid, contactuid, value) {
var new_response = (value) ? 'read' : 'unread';
var prefix = '#' + contactuid;
$('#ur-read-unread-text').html(new_response);
$('#read-unread-dialog').dialog
({
show: "fade",
title: "Change to " + new_response + "?",
modal: true,
resizeable: false,
width: getDialogWidth(400, .9),
maxWidth: 400,
fluid: true,
buttons:
{
Ok: function ()
{
$(this).dialog('close');
$.ajax(
{
// async: false
type: 'POST',
url: '/ajax/set-var.php',
// url: '/ajax/tr-toggle-status.php',
data:
{
'which_function': 'read-unread',
'principalid': principalid,
'repid': repid,
'usertypeid': usertypeid,
'value': value
},
error: function (jqXHR, textStatus, errorThrown)
{
// alert(jqXHR.responseText);
ajaxError('Read-Unread', textStatus, errorThrown);
},
success: function (data, textStatus, jqXHR)
{
if (data)
{
var connector = '\', \'';
if (value)
{
$(prefix + '-unread').remove();
$('<i id="' + contactuid + '-read" class="fa fa-envelope-open tooltip" onclick="toggleReadUnread(\'' + usertypeid + connector + opp_user_label_short + connector + principalid + connector + repid + connector + contactuid + '\'' + ', false);"><span id="' + contactuid + '-read-unread-tt" class="tooltiptext">You have no unread messages from this ' + opp_user_label_short + '</span>').insertAfter(prefix + '-read-unread-placeholder');
}
else
{
$(prefix + '-read').remove();
$('<i id="' + contactuid + '-unread" class="fa fa-envelope tooltip" onclick="toggleReadUnread(\'' + usertypeid + connector + opp_user_label_short + connector + principalid + connector + repid + connector + contactuid + '\'' + ', true);"><span id="' + contactuid + '-read-unread-tt" class="tooltiptext">You have a new message from this ' + opp_user_label_short + '</span>').insertAfter(prefix + '-read-unread-placeholder');
$('.tc-' + contactuid).hide();
}
jConfirm('Success', 'Messages marked "' + new_response + '"');
}
}
})
},
Cancel: function () {
$(this).dialog('close');
}
}
})
}</pre>
<p>编辑1：</p>
<ol>
<li><p>我们仍然与用户遇到此问题。我们仍然无法在内部重现它。</p>
</li>
<li><p>隐身模式可以防止问题发生。虽然这应该是一个很好的线索，但到目前为止还没有帮助我们。它似乎指向会话和缓存问题。我们已经排除了过时的缓存问题。</p>
</li>
<li><p>它是间歇性的，仅影响少数用户。稍后甚至该用户也将不再遇到问题。再次似乎与缓存相关。</p>
</li>
<li><p>我们添加了诊断信息，有时在 ajax 错误抛出中显示“禁止”。检查这意味着它与跨域操作有关。没有进行跨域活动；所有请求都发送到我们自己的服务器。</p>
</li>
<li><p>我们向一些用户询问了他们的扩展程序。在一种情况下，他们没有安装扩展；在另一种情况下，他们只有 Chrome 的 Grammarly 扩展。我们使用该扩展进行了测试，但仍然无法重现该问题。</p>
</li>
<li><p>发生错误时，会显示一个对话框。单击该对话框上的“确定”后，其余操作应该继续进行，因为该对话框没有阻止任何内容。但是，用户报告说，如果不处于隐身模式，他们无法完成该操作。</p>
</li>
</ol>
<p>编辑2：</p>
<p>我开始研究 https-access.log。虽然大多数对 ajax 文件的访问都会返回 200，但也有返回 302 的情况。其含义是“文件已移动”。但文件并未移动，不久之后就恢复正常访问。</p>
<p>这是访问日志的摘录，显示了一系列 200 响应，其中散布着一些 302，然后恢复 200。</p>
<pre class="brush:php;toolbar:false;">108.221.39.97 - - [13/Jan/2023:10:07:52 -0600] "POST /ajax/set-var.php HTTP/2.0" 200 21 "https://www.rephunter.net/track-relationships.php?filter=clear" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/108.0.0.0 Safari/537.36"
108.221.39.97 - - [13/Jan/2023:10:08:34 -0600] "POST /ajax/set-var.php HTTP/2.0" 200 21 "https://www.rephunter.net/track-relationships.php?filter=clear" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/108.0.0.0 Safari/537.36"
108.221.39.97 - - [13/Jan/2023:10:09:56 -0600] "POST /ajax/set-var.php HTTP/2.0" 200 21 "https://www.rephunter.net/track-relationships.php?filter=clear" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/108.0.0.0 Safari/537.36"
73.176.158.231 - - [13/Jan/2023:10:10:21 -0600] "POST /ajax/set-var.php HTTP/2.0" 200 21 "https://www.rephunter.net/track-relationships.php?filter=clear" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/108.0.0.0 Safari/537.36"
74.73.226.238 - - [13/Jan/2023:10:15:07 -0600] "POST /ajax/set-var.php HTTP/2.0" 302 - "https://www.rephunter.net/track-relationships.php?filter=clear" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/108.0.0.0 Safari/537.36"
184.178.239.162 - - [13/Jan/2023:10:15:18 -0600] "POST /ajax/set-var.php HTTP/2.0" 200 21 "https://www.rephunter.net/track-relationships.php?reply=tr-28560-80354" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/108.0.0.0 Safari/537.36 Edg/108.0.1462.76"
74.73.226.238 - - [13/Jan/2023:10:15:20 -0600] "POST /ajax/set-var.php HTTP/2.0" 302 - "https://www.rephunter.net/track-relationships.php?filter=clear" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/108.0.0.0 Safari/537.36"
24.144.188.195 - - [13/Jan/2023:10:15:22 -0600] "POST /ajax/set-var.php HTTP/2.0" 200 21 "https://www.rephunter.net/track-relationships.php?filter=clear" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/109.0.0.0 Safari/537.36"
74.73.226.238 - - [13/Jan/2023:10:15:28 -0600] "POST /ajax/set-var.php HTTP/2.0" 302 - "https://www.rephunter.net/track-relationships.php?filter=clear" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/108.0.0.0 Safari/537.36"
74.73.226.238 - - [13/Jan/2023:10:15:34 -0600] "POST /ajax/set-var.php HTTP/2.0" 302 - "https://www.rephunter.net/track-relationships.php?filter=clear" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/108.0.0.0 Safari/537.36"
74.73.226.238 - - [13/Jan/2023:10:15:37 -0600] "POST /ajax/set-var.php HTTP/2.0" 302 - "https://www.rephunter.net/track-relationships.php?filter=clear" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/108.0.0.0 Safari/537.36"
74.73.226.238 - - [13/Jan/2023:10:15:49 -0600] "POST /ajax/set-var.php HTTP/2.0" 302 - "https://www.rephunter.net/track-relationships.php?filter=clear" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/108.0.0.0 Safari/537.36"
72.38.12.208 - - [13/Jan/2023:10:15:54 -0600] "POST /ajax/set-var.php HTTP/2.0" 200 21 "https://www.rephunter.net/track-relationships.php?reply=tr-43850-7444" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/108.0.0.0 Safari/537.36 Edg/108.0.1462.76"
74.73.226.238 - - [13/Jan/2023:10:16:07 -0600] "POST /ajax/set-var.php HTTP/2.0" 302 - "https://www.rephunter.net/track-relationships.php" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/108.0.0.0 Safari/537.36"
74.73.226.238 - - [13/Jan/2023:10:16:19 -0600] "POST /ajax/set-var.php HTTP/2.0" 302 - "https://www.rephunter.net/track-relationships.php" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/108.0.0.0 Safari/537.36"
108.221.39.97 - - [13/Jan/2023:10:17:23 -0600] "POST /ajax/set-var.php HTTP/2.0" 200 21 "https://www.rephunter.net/track-relationships.php?filter=clear" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/108.0.0.0 Safari/537.36"
108.221.39.97 - - [13/Jan/2023:10:17:28 -0600] "POST /ajax/set-var.php HTTP/2.0" 200 21 "https://www.rephunter.net/track-relationships.php?filter=clear" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/108.0.0.0 Safari/537.36"
72.38.12.208 - - [13/Jan/2023:10:17:49 -0600] "POST /ajax/set-var.php HTTP/2.0" 200 21 "https://www.rephunter.net/track-relationships.php?reply=tr-43850-7444" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/108.0.0.0 Safari/537.36 Edg/108.0.1462.76"
108.221.39.97 - - [13/Jan/2023:10:17:58 -0600] "POST /ajax/set-var.php HTTP/2.0" 200 21 "https://www.rephunter.net/track-relationships.php?filter=clear" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/108.0.0.0 Safari/537.36"
24.45.242.118 - - [13/Jan/2023:10:20:41 -0600] "POST /ajax/set-var.php HTTP/2.0" 200 21 "https://www.rephunter.net/track-relationships.php?filter=clear" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/109.0.0.0 Safari/537.36"
24.45.242.118 - - [13/Jan/2023:10:21:10 -0600] "POST /ajax/set-var.php HTTP/2.0" 200 21 "https://www.rephunter.net/track-relationships.php?filter=clear" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/109.0.0.0 Safari/537.36"</pre>
<p>编辑3：</p>
<p>我们有一个候选解决方案，其灵感来自 @ibrahim 对下面 Lajos Arpad 答案的评论。简而言之，向 ajax 调用添加重试功能，如 https://forum.framework7.io/t/app-request-what-is-the-best-way-to-retry-an-ajax-request-using 所示-app-request/4759，它似乎基于What's the best way to retry an AJAX request on failure using jQuery?。</p>
<p>在我们确认此修复有效后（这将需要一些“没有报告错误”的时间），我会将其标记为“答案”，@ibramim 是否应该发布他关于重试的评论作为答案。</p>
![[Web front-end] Node.js quick start](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
symptom
The AJAX script issue you are experiencing usually works fine, but for some (rare) users, sometimes the file is briefly not found.
Solution
Using incognito mode seems to solve this problem.
Are we sure there is a solution?
There is some slight possibility that the workaround will occur simultaneously, but will not result in AJAX recovery. Therefore, in rare cases, the file may become unavailable for a short period of time (for example, there is an intermittent script rebuild/minimizer that temporarily deletes the file to move a new version to its place), and the user Will encounter the following situation: the problem you mentioned, however, when they try to access it through incognito mode, the file has already been restored, in short: incognito mode may only coincide with the recovery of the file, but it will not cause this Condition.
To counter this, you can try the incognito workaround while the problem is occurring to see if it works, and then try in non-incognito mode to see if it still doesn't work (after the page reloads, of course ). In the second half of the answer, I'm going to assume that incognito mode causes the user's problem to disappear, not just coincides with it disappearing.
possible reason
Cookie
There is a problem with some cookies. For example, a user's cookie expires and is no longer valid, but the page starts loading while the cookie is still valid, but the server throws a file move error on a request for a file because it is programmed to only serve this request to logged in users. Also, /ajax/set-var.php itself may be trying to load some file that certainly exists in an existing session, but the current session has been destroyed and no longer has access to that file.
cache
The client cache may have the exact file name or path and the file has been renamed or moved. It's also possible that the file was requested during the build process, when the file was being written and an incomplete file was cached to the browser. In your case this doesn't seem to be an issue as you have a php file that was moved based on the error message.
The server side may have cached some information for you that has been deprecated/invalid since then. For example, generate static pages for user sessions to avoid repeating the same long request logic.
Session Storage/Local Storage
It is possible that some values are stored in
sessionStorageand are lost when the session times out, but the page is still loading, or that some session-specific values are stored inlocalStorageand is no longer valid. In both cases the request is invalid and some error is thrown on the server side causing the file not to be found.What does it mean if the file cannot be found?
This means that some files were not found in the expected location. So to fix it: