Bug 101646 - should we transmit failed state to tp instead of exhausted candidates ?
Summary: should we transmit failed state to tp instead of exhausted candidates ?
Status: RESOLVED MOVED
Alias: None
Product: Telepathy
Classification: Unclassified
Component: tp-farstream (show other bugs)
Version: git master
Hardware: Other All
: medium normal
Assignee: Olivier Crête
QA Contact: Telepathy bugs list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-06-29 11:44 UTC by Fabrice Bellet
Modified: 2019-12-03 19:16 UTC (History)
0 users

See Also:
i915 platform:
i915 features:

Attachments

Description Fabrice Bellet 2017-06-29 11:44:08 UTC 
I'm not sure of this case, but the code handling the conversion from FS_STREAM_STATE_* to TP_STREAM_ENDPOINT_STATE_* looks a bit strange to me in cb_fs_component_state_changed():

>  switch (fsstate)
>  {
>    default:
>      g_warning ("Unknown Farstream state, returning ExhaustedCandidates");
>      /* fall through */
>    case FS_STREAM_STATE_FAILED:
>      state = TP_STREAM_ENDPOINT_STATE_EXHAUSTED_CANDIDATES;
>      break;

Why is state EXHAUSTED_CANDIDATES returned in case of failure, instead of TP_STREAM_ENDPOINT_STATE_FAILED ?
Comment 1 Olivier Crête 2017-06-29 13:30:56 UTC 
I think this links to the previous patch. I think exhausted candidate means we've failed, but we could still succeed if more candidates were provided. The failed one means a hard failure.
Comment 2 GitLab Migration User 2019-12-03 19:16:55 UTC 
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/telepathy/telepathy-farstream/issues/8.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.