FAIL: t2000-fcfs.t 2 - sim: scheduled and ran all jobs

[garlick]

When pr #246 was submitted, travis failed against the current flux-core master.

PASS: t2000-fcfs.t 1 - sim: started successfully
FAIL: t2000-fcfs.t 2 - sim: scheduled and ran all jobs
PASS: t2000-fcfs.t 3 - jobs scheduled in correct order
ERROR: t2000-fcfs.t - exited with status 1
PASS: t2001-fcfs-aware.t 1 - sim: started successfully
FAIL: t2001-fcfs-aware.t 2 - sim: scheduled and ran all jobs
PASS: t2001-fcfs-aware.t 3 - jobs scheduled in correct order
ERROR: t2001-fcfs-aware.t - exited with status 1
PASS: t2002-easy.t 1 - sim: started successfully
FAIL: t2002-easy.t 2 - sim: scheduled and ran all jobs
FAIL: t2002-easy.t 3 - jobs scheduled in correct order
ERROR: t2002-easy.t - exited with status 1

Debugging this, the problem seems to have been introduced between flux core pr 1082 (May 31) and 1079 (May 25), not by pr #246 (see the pr for some more details).

As discussed in our meeting, I'll disable the failing tests in pr #246, and then once we get that merged and sched can compile against the flux-core master again, we can debug the other problem.

[SteVwonder]

Just a checkpoint on my progress....I tracked down why the simulator modules were not properly sending/receiving requests. Most of the requests are created in the following way:

msg = flux_msg_create (FLUX_MSGTYPE_REQUEST);
flux_msg_set_topic (msg, topic);
flux_msg_set_json (msg, Jtostr (o));

switching that to:

msg = flux_request_encode (topic, Jtostr(o));

solves the problem (most likely because the enable_route function is actually being called now).

Now I'm getting a segfault once the simulator starts, which I am currently investigating.

[garlick]

If this is a fire and forget request, you could encode and send in one go with

flux_future_t *f;
f = flux_rpc (h, topic, Jtostr (o), FLUX_NODEID_ANY, FLUX_RPC_NORESPONSE);
if (!f) {
    // handle error
}
flux_future_destroy (f);