【Workflow APi 】【Get Workflow Run Detail】Inconsistency between return type and interface documentation

[guoshiqiufeng]

Self Checks

• [x] This is only for bug report, if you would like to ask a question, please head to Discussions.
• [x] I have searched for existing issues search for existing issues, including closed ones.
• [x] I confirm that I am using English to submit this report (我已阅读并同意 Language Policy).
• [x] [FOR CHINESE USERS] 请务必使用英文提交 Issue，否则会被关闭。谢谢！:）
• [x] Please do not modify this template :) and fill in all the required fields.

Dify version

1.0.1

Cloud or Self Hosted

Self Hosted (Docker)

Steps to reproduce

Get Workflow Run Detail

API /workflows/run/:workflow_id

Shouldn't it be timestamp, but now it's just the time returned?

✔️ Expected Behavior

{ "id": "b1ad3277-089e-42c6-9dff-6820d94fbc76", "workflow_id": "19eff89f-ec03-4f75-b0fc-897e7effea02", "status": "succeeded", "inputs": "{"sys.files": [], "sys.user_id": "abc-123"}", "outputs": null, "error": null, "total_steps": 3, "total_tokens": 0, "created_at": 1741771765, "finished_at": 1741771775, "elapsed_time": 30.098514399956912 }

❌ Actual Behavior

{ "id": "b1ad3277-089e-42c6-9dff-6820d94fbc76", "workflow_id": "19eff89f-ec03-4f75-b0fc-897e7effea02", "status": "succeeded", "inputs": "{"sys.files": [], "sys.user_id": "abc-123"}", "outputs": null, "error": null, "total_steps": 3, "total_tokens": 0, "created_at": "Thu, 18 Jul 2024 03:17:40 -0000", "finished_at": "Thu, 18 Jul 2024 03:18:10 -0000", "elapsed_time": 30.098514399956912 }

[dosubot[bot]]

@guoshiqiufeng Hello there! I'm here to assist you with bugs, questions, and contributions. Let me know how I can help while you're waiting for a human maintainer.

The Dify API documentation specifies that the created_at and finished_at fields in the /workflows/run/:workflow_id endpoint response are expected to be in the RFC 1123 date-time format, such as "Thu, 18 Jul 2024 03:17:40 -0000" ^[1]. This matches the actual behavior you are observing, where the timestamps are returned as formatted date-time strings rather than Unix timestamps. If the documentation or your expectations indicate a different format, it might be worth checking for any configuration settings that could affect the timestamp format, such as the current_time tool's format parameter ^[2].

To continue talking to Dosu, mention @dosu.

---

^{Help Dosu learn! Give it feedback: Great Response | Irrelevant Answer | Incorrect Sources | Too Verbose | Hallucination | Bug Report | Other}