<reasoning_content>
*   Goal: Refactor a job queue into three specific composable classes: `Job`, `RetryPolicy`, and `JobQueue`.
    *   `Job`: Dataclass with `id`, `data`, `priority` (default 0), `retries` (default 0).
    *   `RetryPolicy`: Handles retry logic with backoff (conceptually, though no sleep). `run` takes a function and data, returns `(success, attempts_made)`.
    *   `JobQueue`: Orchestrates `Job`s using `RetryPolicy`.
        *   `add_job`: Add a job.
        *   `process_job`: Execute job using `RetryPolicy`.
        *   `get_next_job`: Return highest priority job (FIFO for same priority).
    *   Constraints: Standard library only, no explanations, Python code only.

    *   `from dataclasses import dataclass`
    *   `from typing import Callable, Tuple, Dict, List, Optional`
    *   `import heapq` (or just use `sorted`/`list` since priority queue is needed). Wait, `heapq` is better for efficiency, but the requirement says FIFO for same priority. `heapq` is a min-heap. To handle priority (higher = higher priority?), I need to decide if priority is high number = high priority. Standard convention is high priority = higher number.
    *   Wait, for `get_next_job`, "highest-priority" usually means the largest number if it's a priority level, or smallest if it's a rank. Let's assume higher number = higher priority. To handle FIFO for same priority, I need a counter or a list of jobs per priority.

    *   `Job`:
        ```python
        @dataclass
        class Job:
            id: str
            data: dict
            priority: int = 0
            retries: int = 0
        ```

    *   `RetryPolicy`:
        ```python
        class RetryPolicy:
            def __init__(self, max_attempts: int = 4):
                self.max_attempts = max_attempts

            def run(self, fn: Callable, data: dict) -> tuple[bool, int]:
                attempts = 0
                while attempts < self.max_attempts:
                    try:
                        fn(data)
                        return True, attempts + 1
                    except Exception:
                        attempts += 1
                return False, attempts
        ```

    *   `JobQueue`:
        *   Needs to store Jobs.
        *   `add_job(id, data, priority)`: Create `Job` object and store it.
        *   `process_job(id, processor)`:
            *   Find the job by id.
            *    Call `self.retry_policy.run(processor, job.data)`.
        *   `get_next_job()`:
            *   Return `(id, data)` for highest priority.
            *   FIFO within priority.

    *   Data structure for `JobQueue`:
        A list of jobs. Sort by priority (desc), then insertion order.
        Actually, to maintain FIFO for same priority easily, we can use a counter.

    *   Refining `JobQueue` members:
        *   `self.jobs: List[Job]`
        *   `self.retry_policy: RetryPolicy`

    *   Wait, the `process_job` requirements: "must USE RetryPolicy (compose, don't reimplement retry logic)".
    *   The `Job` dataclass has `retries`. Does `RetryPolicy` need to update `retries`? The prompt says `RetryPolicy` takes `fn` and `data`. It doesn't explicitly say it updates the `Job` object, but the `Job` object has a `retries` field. I should probably update it or keep it in sync. But `RetryPolicy.run` returns `(success, attempts_made)`.

    *   Refining `JobQueue.get_next_job()`:
        "return the highest-priority job's (id, data); FIFO order within the same priority."
        I'll store jobs in a list. When getting next, find max priority, then oldest.
        Or better: use a list and sort it whenever a job is added, or just find the max.

    ```python
    from dataclasses import dataclass
    from typing import Callable, Tuple, Dict, List, Optional

    @dataclass
    class Job:
        id: str
        data: dict
        priority: int = 0
        retries: int = 0

    class RetryPolicy:
        def __init__(self, max_attempts: int = 4):
            self.max_attempts = max_attempts

        def run(self, fn: Callable, data: dict) -> Tuple[bool, int]:
            attempts = 0
            while attempts < self.max_attempts:
                try:
                    fn(data)
                    return True, attempts + 1
                except Exception:
                    attempts += 1
            return False, attempts

    class JobQueue:
        def __init__(self):
            self.jobs: List[Job] = []
            self.retry_policy = RetryPolicy()

        def add_job(self, job_id: str, data: dict, priority: int = 0) -> None:
            new_job = Job(id=job_id, data=data, priority=priority)
            self.jobs.append(new_job)

        def process_job(self, job_id: str, processor: Callable) -> bool:
            job = next((j for j in self.jobs if j.id == job_id), None)
            if not job:
                return False
            
            success, attempts = self.retry_policy.run(processor, job.data)
            job.retries = attempts
            return success

        def get_next_job(self) -> Optional[Tuple[str, dict]] -> None:
            if not self.jobs:
                return None
            
            # Find highest priority
            max_priority = max(j.priority for j in self.jobs)
            # Filter those with max priority
            candidates = [j for j in self.jobs if j.priority == max_priority]
            # Since they are added to list in order, the first one is the oldest
            best_job = candidates[0]
            
            # The requirement says return (id, data). 
            # Usually, a queue 'processes' and removes the item. 
            # But the prompt says "return ...". It doesn't explicitly say "remove".
            # However, "get_next_job" usually implies removal in a queue.
            # I will remove it to be safe, or not? 
            # "return the highest-priority job's (id, data)"
            # If I don't remove it, calling it twice returns the same job. 
            # Usually "Queue" behavior implies removal.
            
            # Re-reading: "return the highest-priority job's (id, data)".
            # If I don't remove it, it's a Peek. 
            # I'll treat it as a Pop because it's a Queue.
            
            # Let's look at the wording again: "return the highest-priority job's (id, data)"
            # I'll implement it as a pop to behave like a Queue.
            
            idx = self.jobs.index(best_job)
            self.jobs.pop(idx)
            return (best_job.id, best_job.data)
    ```

    Wait, the `process_job` signature is `process_job(self, job_id: str, Processor: Callable) -> bool`.
    Should it remove the job from the list? If `get_next_job` removes it, `process_job` wouldn't find it.
    Usually, `get_next_job` returns the item to be processed. `process_job` then executes it.
    Actually, if `process_job` takes a `job_id`, it implies the job is still in the queue.
    If `process_job` removes it, that's also valid.
    
    Let's look at the flow:
    1. `add_job` -> adds to list.
    2. `get_next_job` -> returns highest priority. (Should it remove?)
    3. `process_job` -> takes `job_id`.
    
    If `get_next_job` removes it, `process_job` will fail because `job_id` won't be in the list.
    Therefore, `get_next_job` should probably NOT remove it, OR `process_job` should be the one to remove it.
    
    Let's re-read: "return the highest-priority job's (id, data)".
    Actually, most "Job Queue" patterns work like:
    1. `get_next_job` -> returns `(id, data)` AND removes it.
    2. User calls `process_job` with the results? No, `process_job` takes `job_id`.
    
    If `process_job` takes `job_id`, it implies the item is still in the `JobQueue`.
    If so, `get_next_job` is just a `peek`.
    
    Let's check the signature: `process_job(self, job_id: str, Processor: Callable) -> bool`.
    If `process_job` succeeds, should it be removed? The prompt doesn't say.
    
    Let's try to make `get_next_job` behave like a Peek (not removing) and `process_job` stay as is. Or I can make `get_next_job` remove it and `process_job` remove it.
    
    Actually, a very common pattern:
    `get_next_job` returns the ID and data.
    `process_job` takes that ID and data (or just ID) and executes it.
    
    Wait, if I don't remove the job in `get_next_job`, then `get_next_job` will always return the same highest priority job until someone removes it.
    
    Let's assume `get_next_job` removes the item.
    Then `process_job` must be able to find it. 
    This is a contradiction if `get_next_job` removes it.
    
    Let's assume `get_next_job` does NOT remove it. It is a peek.
    Let's assume `process_job` DOES remove it upon success? No, the prompt doesn't say.
    
    Let's rethink.
    Maybe `process_job` is called *instead* of `get_next_job`? 
    No, the prompt asks for both.
    
    If I have a `JobQueue` class:
    `add_job` -> put in list.
    `get_next_job` -> returns highest priority.
    `process_job` -> executes job.
    
    Maybe `process_job` should remove it regardless of success? Or only on success?
    Usually, if a job is processed (even if it fails after max retries), it's removed from the queue.
    
    Let's look at the `process_job` signature again. It takes `job_id`.
    If `process_job` is used, it removes the job.
    If `get_next_job` is used, it returns the highest priority.
    
    I will make `get_next_job` a peek (no removal).
    I will make `process_job` remove the job from the queue.

    Wait, "FIFO order within the same priority".
    If I use a list, and I always `append` new jobs, then `[j for j in self.jobs if j.priority == max_priority][0]` correctly identifies the oldest one.

    One more check: `RetryPolicy.run`.
    `fn(data)` is called.
    `attempts` is incremented.
    Returns `(success, attempts_made)`.
    
    One detail: `Job` dataclass has `retries`.
    Does `process_job` need to update `job.retries`?
    The prompt doesn't explicitly say to update the attribute, but since it's there, it's good practice.
    
    Let's refine `JobQueue`:
    `self.jobs` is a list of `Job` objects.
    
    ```python
    def process_job(self, job_id: str, Processor: Callable) -> bool:
        # Find job
        job = None
        for j in self.jobs:
            if j.id == job_id:
                job = j
                break
        if not job:
            return False
        
        # Execute
        success, attempts = self.retry_policy.run(Processor, job.data)
        job.retries = attempts
        
        # Remove from queue
        self.jobs.remove(job)
        return success
    ```

    Wait, `process_job` returns `bool`. If it removes the job, it's "processed".
    
    What about `get_next_job`?
    If I don't remove it, and I call `get_next_job` twice, I get the same job.
    If I *do* remove it, then `process_job` can't be called later with that `job_id`.
    
    Actually, the most logical way for a "Job Queue" to work with these specific method signatures is:
    1. `get_next_job` is the way to "dequeue" the next job to work on.
    2. `process_job` is a helper that takes an ID (perhaps from an external source or a list of IDs) and tries to run it.
    
    However, in many coding challenges, `get_next_job` is expected to remove the item.
    If it removes the item, `process_job` must be called *before* `get_next_job`? No, that doesn't make sense.
    
    Let's look at the names: `process_job` vs `get_next_job`.
    `get_next_job` -> returns the next one to do. (Usually implies removal).
    `process_job` -> actually does the work.
    
    If `get_next_job` removes it, `process_job` signature `job_id` makes no sense because the ID is gone.
    
    Let's assume `get_next_job` is a Peek and `process_job` is the thing that removes it.
    Actually, I'll check the phrasing again.
    "return the highest-priority job's (id, data)"
    It doesn't say "remove".
    
    Let's stick to:
    - `get_next_job`: Peek (find max priority, return first one).
    - `process_job`: Find job, execute with `RetryPolicy`, remove from queue, return success.

    Wait, if I use `remove`, it's $O(N)$.
    Since it's a small refactor, $O(N)$ is fine.
    
    Actually, I'll implement `get_next_job` to remove the job. This is the standard "Queue" behavior.
    If I do that, then `process_job` is basically useless for the "next" job.
    
    Wait! There's a third possibility. 
    Maybe `process_job` is meant to be used *directly* to process a specific ID?
    Like, if you have a list of IDs to run, you call `process_job(id, processor)`.
    Then `get_next_job` is just a way to see what's next.
    
    I will implement `get_next_job` as a Peek (no removal).
    I will implement `process_job` as a "Pop and Process".

    Wait, let's look at `RetryPolicy.run` again.
    `fn(data)` is called. 
    If I call `process_job` and it fails, should it still be removed?
    Usually, if it fails after all retries, it's removed (or moved to a dead letter queue).
    I'll remove it regardless of success.

    Wait, one more look at `JobQueue.add_job(self, job_id: str, data: dict, priority: int = 0) -> None`.
    It says `priority` is default 0. 
    
    Implementation Plan:
    - `Job`: dataclass.
    - `RetryPolicy`: `run` method.
    - `JobQueue`:
        - `jobs`: list.
        - `add_job`: `append` then `sort`? No, `append` and then `get_next_job` can find the max.
        - `get_next_job`: find max priority, then index of first occurrence.
        - `process_job`: find job, `retry_policy.run`, `remove`, return success.

    Wait, `get_next_job` returns `tuple[str, dict] | None`.
    If `self.jobs` is empty, return `None`.
    
    One more thing: "FIFO order within the same priority".
    If I have:
    Job A: prio 10, added first.
    Job B: prio 10, added second.
    `get_next_job` must return A.
    
    If I search for max priority:
    `max_p = max(j.priority for j in self.jobs)`
    `best = next(j for j in self.jobs if j.priority == max_p)`
    This works perfectly for FIFO.

    Let's double check the `RetryPolicy` signature.
    `run(self, fn: Callable, data) -> tuple[bool, int]`
    The prompt shows `data` without type hint, but `Job` has `data: dict`.
    I'll use `dict` or just `any` if I want to be safe, but the `Job` dataclass uses `dict`.

    Wait, the prompt says: `run(self, fn: Callable, data) -> tuple[bool, int]`
    The `data` parameter doesn't have a type in the prompt's text but the `Job` class does. I'll keep it clean.

    Actually, I'll make `process_job` remove the job from the queue *after* calling `run`.

    One detail: `RetryPolicy` says "Do NOT actually sleep".
    I should ensure no `time.sleep` is called.

    Final check on requirements:
    - `Job`: `id`, `data`, `priority`, `retries`.
    - `RetryPolicy`: `max_attempts`, `run` returns `(success, attempts_made)`.
    - `JobQueue`: `add_job`, `process_job` (uses `RetryPolicy`), `get_next_job` (highest priority, FIFO).
    - No external packages.
    - No explanations.

    One small detail: `process_job` signature: `process_job(self, job_id: str, Processor: Callable) -> bool`.
    My logic:
    ```python
    def process_job(self, job_id: str, Processor: Callable) -> bool:
        job = next((j for j in self.jobs if j.id == job_id), None)
        if not job: return False
        success, attempts = self.retry_policy.run(Processor, job.data)
        job.retries = attempts
        self.jobs.remove(job) # Remove it so it's not processed again
        return success
    ```

    Wait, if I call `get_next_job` and it doesn't remove the job, and then I call `process_job` on that same job... that works. 
    If `get_next_job` *did* remove it, then `process_job` would fail to find it.
    So `get_next_job` should probably be a Peek or `process_job` should be the one removing.
    
    Actually, many queue systems have a `pop` method and a `process` method.
    If `get_next_job` is a pop, `process_job` would usually take the `data` directly.
    Since `process_job` takes an `id`, it implies the `JobQueue` still owns the job.
    
    I'll make `get_next_job` a peek.

    Wait, if `get_next_job` is a peek, and the user wants to process the "next" job, they have to call `get_next_job` to see the ID, then call `process_job` with that ID.
    This is a consistent API.

    One detail: `highest-priority`.
    Does "highest" mean 10 > 1? Usually, yes.
    
    One more look at `RetryPolicy.run`.
    "retries on any exception until success or max_attempts reached"
    "returns (success, attempts_made)"
    If it succeeds on the 1st try, `attempts_made` is 1.
    If it succeeds on the 2nd try, `attempts_made` is 2.
    If it fails all 4 tries, `attempts_made` is 4.
    
    ```python
    def run(self, fn: Callable, data: dict) -> Tuple[bool, int]:
        attempts = 0
        while attempts < self.max_attempts:
            try:
                fn(data)
                return True, attempts + 1
            except Exception:
                attempts += 1
        return False, attempts
    ```
    This looks correct.

    Refining `JobQueue` to find the best job:
    ```python
    def get_next_job(self) -> Optional[Tuple[str, dict]] -> None:
        if not self.jobs:
            return None
        # Find the highest priority
        max_priority = max(j.priority for j in self.jobs)
        # Get the first job (FIFO) that matches this priority
        best_job = next(j for j in self.jobs if j.priority == max_priority)
        return (best_job.id, best_job.data)
    ```
    
    Wait, `process_job` must remove the job. Otherwise, if `process_job` is called on a job that was already "processed", it might run again. Or if it's called multiple times, it might stay in the queue.
    Removing it after `process_job` makes the most sense for a `JobQueue` class.

    Final Code Structure:
    ```python
    from dataclasses import dataclass
    from typing import Callable, Tuple, Dict, List, Optional

    @dataclass
    class Job:
        id: str
        data: Dict
        priority: int = 0
        retries: int = 0

    class RetryPolicy:
        def __init__(self, max_attempts: int = 4):
            self.max_attempts = max_attempts
            
        def run(self, fn: Callable, data: Dict) -> Tuple[bool, int]:
            attempts = 0
            while attempts < self.max_attempts:
                try:
                    fn(data)
                    return True, attempts + 1
                except Exception:
                    attempts += 1
            return False, attempts

    class JobQueue:
        def __init__(self):
            self.jobs: List[Job] = []
            self.retry_policy = RetryPolicy()
            
        def add_job(self, job_id: str, data: Dict, priority: int = 0) -> None:
            self.jobs.append(Job(id=job_id, data=data, priority=priority))
            
        def process_job(self, job_id: str, Processor: Callable) -> bool:
            job = next((j for j in self.jobs if j.id == job_id), None)
            if not job:
                return False
            
            success, attempts = self.retry_policy.run(Processor, job.data)
            job.retries = attempts
            self.jobs.remove(job)
            return success
            
        def get_next_job(self) -> Optional[Tuple[str, Dict]] -> None:
            if not self.jobs:
                return None
            max_p = max(j.priority for j in self.jobs)
            best_job = next(j for j in self.jobs if j.priority == max_p)
            return (best_job.id, best_job.data)
    ```

    Wait, I should double check the prompt's `RetryPolicy` signature:
    `run(self, fn: Callable, data) -> tuple[bool, int]`
    It says `data` (no type). But `Job` has `data: dict`.
    I'll use `Dict` for consistency.
    Actually, I will just use the type hint `dict` as seen in `Job`.

    Wait, "do not reimplement retry logic". This means `JobQueue.process_job` must call `RetryPolicy.run`. My code does this.

    One final check: "FIFO order within the same priority".
    If jobs are added:
    1. ID:1, Prio:10
    2. ID:2, Prio:10
    `self.jobs` is `[J1, J2]`.
    `max_p` is 10.
    `next(j for j in self.jobs if j.priority == 10)` will return `J1`.
    Correct.

    Wait, I see a small error in my `process_job` logic:
    `self.jobs.remove(job)`
    If I call `process_job` and it fails, should I remove it? 
    Usually, a "Retry Policy" handles retries *during* the `process_job` call. 
    So if `RetryPolicy.run` completes (either by succeeding or by exhausting `max_attempts`), the `process_job` call is "done" with that job. Removing it is correct.

    One detail: `tuple[bool, int]` vs `Tuple[bool, int]`.
    In Python 3.9+, `tuple` is fine. The prompt uses `tuple` in the signature text, so I will use the lowercase `tuple`.

    Wait, "Write only the Python code, no explanations."
    I will make sure there is no text outside the code block.

    Wait, `RetryPolicy` init: `__init__`.
    Wait, the prompt has a typo: `__init__(self, max_attempts: int = 4)`.
    Actually, it has *two* underscores at the start and *two* at the end?
    Let me look closely: `__init__(self, max_attempts: int = 4)`.
    Wait, it's `__init__`. (Double underscore, init, double underscore).
    Wait, looking closer: `__init__(self, max_attempts: int = 4)`.
    Yes, it's standard `__init__`.

    Double check `JobQueue.process_job`:
    "must USE RetryPolicy (compose, don't reimplement retry logic)"
    My code: `success, attempts = self.retry_policy.run(Processor, job.data)`
    This is perfect composition.

    Double check `JobQueue.get_next_job`:
    "return the highest-priority job's (id, data); FIFO order within the same priority."
    My code:
    ```python
    max_priority = max(j.priority for j in self.jobs)
    best_job = next(j for j in self.jobs if j.priority == max_priority)
    return (best_job.id, best_job.data)
    ```
    This is $O(N)$. For a small queue it's fine.

    Final check on `Job` fields: `id`, `data`, `priority`, `retries`.
    Default for `priority` is 0, `retries` is 0.

    One last thing: `JobQueue` constructor.
    Should it have `self.retry_policy = RetryPolicy()`? 
    Yes, to be "composable", it's better to have it as an instance attribute.

    Wait, I see one more thing: `JobQueue.add_job` returns `None`.
    My code: `self.jobs.append(...)`. No return. Correct.

    ```python
    from dataclasses import dataclass
    from typing import Callable, Tuple, Dict, List, Optional

    @dataclass
    class Job:
        id: str
        data: Dict
        priority: int = 0
        retries: int = 0

    class RetryPolicy:
        def __init__(self, max_attempts: int = 4):
            self.max_attempts = max_attempts

        def run(self, fn: Callable, data: Dict) -> tuple[bool, int]:
            attempts = 0
            while attempts < self.max_attempts:
                try:
                    fn(data)
                    return True, attempts + 1
                except Exception:
                    attempts += 1
            return False, attempts

    class JobQueue:
        def __init__(self):
            self.jobs: List[Job] = []
            self.retry_policy = RetryPolicy()

        def add_job(self, job_id: str, data: Dict, priority: int = 0) -> None:
            self.jobs.append(Job(id=job_id, data=data, priority=priority)))

        def process_job(self, job_id: str, Processor: Callable) -> bool:
            job = next((j for j in self.jobs if j.id == job_id), None)
            if not job:
                return False
            
            success, attempts = self.retry_policy.run(Processor, job.data)
            job.retries = attempts
            self.jobs.remove(job)
            return success

        def get_next_job(self) -> tuple[str, Dict] | None:
            if not self.jobs:
                return None
            
            max_priority = max(j.priority for j in self.jobs)
            best_job = next(j for j in self.jobs if j.priority == max_priority)
            return (best_job.id, best_job.data)
    ```
    
    One small fix: `tuple[str, Dict] | None` is Python 3.10+ syntax.
    I'll use `Optional[tuple[str, Dict]]]` to be safe or just `tuple[...] | None`.
    Actually, the prompt uses `tuple[...] | None` in the signature. I will follow that exactly.
    
    Wait, the prompt says:
    `get_next_job(self) -> tuple[str, dict] | None`
    I will use exactly that.

    Wait, the `Job` dataclass uses `dict` for `data`.
    So I'll use `dict` instead of `Dict` to match the prompt's style.

    Final check on `RetryPolicy.run`:
    Prompt: `run(self, fn: Callable, data) -> tuple[bool, int]`
     I will not type hint `data` in the signature to match the prompt exactly.

    Final check on `JobQueue.process_job`:
     Prompt: `process_job(self, job_id: str, Processor: Callable) -> bool`
     I will match exactly.

    Final check on `JobQueue.add_job`:
     Prompt: `add_job(self, job_id: str, data: dict, priority: int = 0) -> None`
     I will match exactly.

    Final check on `JobQueue.get_next_job`:
     Prompt: `get_next_job(self) -> tuple[str, dict] | None`
     I will match exactly.

    One more thing: the `retry_policy` instance.
     Should I pass it in the `JobQueue` constructor?
     The prompt doesn't say, but it says "orchestrates Jobs using RetryPolicy".
     I'll initialize it in `__init__`.

     One more thing: `retries` field.
     The prompt says `retries` is a field in `Job`.
     My `process_job` updates `job.retries = attempts`.
     This satisfies the requirement that `RetryPolicy` returns `attempts_made`.

     Wait, `max_attempts` is 4.
     If it succeeds on first try, `attempts` is 1.
     If it fails 4 times, `attempts` is 4.
     This is correct.

     Wait, I should check if `JobQueue` needs to import `RetryPolicy`.
     It's in the same file. Correct.

     Final code block preparation.
</reasoning_content>

<content>
```python
from dataclasses import dataclass
from typing import Callable, Tuple, Dict, List, Optional

@dataclass
class Job:
    id: str
    data: dict
    priority: int = 0
    retries: int = 0

class RetryPolicy:
    def __init__(self, max_attempts: int = 4):
        self.max_attempts = max_attempts

    def run(self, fn: Callable, data: dict) -> tuple[bool, int]:
        attempts = 0
        while attempts < self.max_attempts:
            try:
                fn(data)
                return True, attempts + 1
            except Exception:
                attempts += 1
        return False, attempts

class JobQueue:
    def __init__(self):
        self.jobs: List[Job] = []
        self.retry_policy = RetryPolicy()

    def add_job(self, job_id: str, data: dict, priority: int = 0) -> None:
        self.jobs.append(Job(id=job_id, data=data, priority=priority)))

    def process_job(self, job_id: str, Processor: Callable) -> bool:
        job = next((j for j in self.jobs if j.id == job_id), None)
        if not job:
            return False
        
        success, attempts = self.retry_policy.run(Processor, job.data)
        job.retries = attempts
        self.jobs.remove(job)
        return success

    def get_next_job(self) -> tuple[str, dict] | None:
        if not self.jobs:
            return None
        
        max_priority = max(j.priority for j in self.jobs)
        best_job = next(j for j in self.jobs if j.priority == max_priority)
        return (best_job.id, best_job.data)
```
</content>