Reject? Cannot reproduce? or what?

[Salman (Sam)]

If a developer is working on a defect and it turned out to be a deployment issue or build issue(i.e. build was not properly deployed to the test environment or your changes are not in the build etc), how should the developer respond to this defect?

Should a developer reject that issue?

Should a developer mark it as cannot reproduce? 

Or there should be some different state in the workflow?

[Cheney Ma [Go2Group]]

How to respond a defect is usually described in your QA/DEV process/workflow document, a develper/QA makes proper response according to that doc.
First of all, you should figure out the root cause of the issue, and then assign the issue back (or reject) to the person who is responsible for that types issue.
In your case, I would suggest below:
1) If the changes (fix) is not merged in the build, it means that it is a build (coding) issue, so it should be fixed by DEV team (maybe not you). You shouldn't reject it, instead, you should assign it to the DEV who is responsible for build creation.
2) If it is not a build issue but a deployment issue to the test environment, then you should reject it and add some comment to the issue to explain why it is rejected.

For JIRA workflow, you should customize it according to you QA/DEV process/workflow document. You can add/delete any states based your team's requirement.

Cheney